7 Jun
2004
7 Jun
'04
11:28 a.m.
On Friday 04 June 2004 14:18, torbenh(a)gmx.de wrote:
On Fri, Jun 04, 2004 at 10:16:53AM +0200, Werner
Schweer wrote:
pthread_self() is broken in your case.
i have seen this behaviour in a signal handler with an alternate stack.
my pthread_implementation does not use thread local storage and
therefore pthread_self uses the stack to identify the thread.
newer glibc should be using %gs for this stuff.
but your %gs register is 0.
very strange.
can you check what the registers contain using breakpoints ?
gdb> info registers
it would be nice if you can find out with what options your glibc is
configured with.
this must be a glibc issue because its working for marek, who uses the
same glibc i do.
i do not remember the configure options for my glibc 2.3.3. I replaced it this
weekend with a brand new version 2.3.4 (nptl). And it now works! So i believe
it was a glibc problem on my system.
Googling around i found the following information about glibc and %gs usage
in the thread implementation:
(http://www-124.ibm.com/developerworks/oss/jikesrvm/userguide/HTML/faq_build…):
"In order for our m-to-n threading scheme to work, we need to be able to swap
stacks for a single pthread. This only works if glibc is built with an option
to use the GS segment register to address certain pthread-specific state.
Otherwise, glibc attempts to use stack-pointer arithmetic to find
pthread-specific state, which fails once we bash the stack.
On Red Hat? Linux and SuSE® Linux, glibc is built with this option by default.
On Debian® GNU/Linux, as of this writing (6 May 2004), the version of x86
libc6
in the Debian Woody distribution does not use GS-segment addressing.
Debian/Sarge
will use GS-segment addressing on 2.6 Linux kernels, but will not use it on
2.4 and 2.2 kernels."
/werner
On Thursday 03 June 2004 20:52, torbenh(a)gmx.de
wrote:
hmm... ok... then we will need to adapt libfst to the new wine_init call,
to be prepared for the next release.
do you already know what #if i need ?
On Thu, Jun 03, 2004 at 08:20:03PM +0200, Werner
Schweer wrote:
its from cvs, last updated yesterday (03.06.2004). On Thursday 03 June 2004 19:33, Mark Knecht
wrote:
> torbenh(a)gmx.de wrote:
my changed libwinelib.c looks like this:
int
SharedWineInit (void (*sighandler)(int,siginfo_t*,void*))
{
unsigned char Error[2024]="";
char *WineArguments[] = {"sharedapp", LIBPATH "/libfst.so",
NULL}; void* stackbase;
size_t stacksize;
void *ntdll;
void *ntso;
char ntdllpath[PATH_MAX+1];
char* dlerr;
char* env[] = { NULL };
sharedwine_signal_handler = sighandler;
if (setjmp (jump) == 0) {
wine_init (2, WineArguments, env, Error, sizeof (Error));
...
which wine version are you using ?
i really dont know where this env parameter comes from.
we have copied some code out of wine and libfst uses this.
(its the threading code from wine)
if this code is expected to behave differently than it does
your pretty much doomed. please
get your wine from www.winehq.org
i tried again with wine-20040505. Calling fstconfig produces a core
dump. Gdb says:
(gdb) bt
#0 __pthread_sighandler (signo=11, ctx=
{gs = 0, __gsh = 0, fs = 51, __fsh = 0, es = 123, __esh = 0, ds =
123, __dsh = 0, edi = 131120, esi = 0, ebp = 1080816716, esp =
1080816708, ebx = 1075170628, edx = 0, ecx = 1, eax = 1082129376, trapno
= 14, err = 4, eip = 1075232782, cs = 115, __csh = 0, eflags = 2163206,
esp_at_signal = 1080816708, ss = 123, __ssh = 0, fpstate = 0x0, oldmask =
2147483648, cr2 = 1082129788})
at sighandler.c:28
#1 <signal handler called>
#2 0x4016c00e in __pthread_internal_tsd_get (key=1077936127) at
specific.c:225
#3 0x400a434e in __libc_calloc (n=1, elem_size=1077936127) at
malloc.c:3585 #4 0x400d7813 in __opendir (name=0x20000 <Address 0x20000
out of bounds>) at ../sysdeps/unix/opendir.c:146
#5 0x40315820 in wine_nt_to_unix_file_name (nameW=0x406bfb58,
unix_name_ret=0x406bfb50, disposition=1, check_case=0 '\0')
at directory.c:873
#6 0x403164e0 in RtlDoesFileExists_U (file_name=0x40380750)
at directory.c:1215
#7 0x40328273 in RtlDosSearchPath_U (paths=0x40380510,
search=0x406bfe08, ext=0x0, buffer_size=64, buffer=0x406bfd2c,
file_part=0x406bfc68) at path.c:428
#8 0x40320e29 in load_dll (load_path=0x40380510, libname=0x406bfe08,
flags=0, pwm=0x406bfe00) at loader.c:1359
#9 0x40320093 in fixup_imports (wm=0x403806c8, load_path=0x40380510)
at loader.c:384
#10 0x40322262 in LdrInitializeThunk (main_file=0x0, unknown2=0,
unknown3=0, unknown4=0) at loader.c:1930
#11 0x4051296b in start_process (arg=0x0) at process.c:822
its essential the same as in the current wine cvs version.
My system uses glibc 2.3.2, linux 2.6.7-rc1 (no nptl).