On Friday 04 June 2004 14:18, torbenh@xxxxxx wrote: > On Fri, Jun 04, 2004 at 10:16:53AM +0200, Werner Schweer wrote: > > On Thursday 03 June 2004 20:52, torbenh@xxxxxx wrote: > > > On Thu, Jun 03, 2004 at 08:20:03PM +0200, Werner Schweer wrote: > > > > On Thursday 03 June 2004 19:33, Mark Knecht wrote: > > > > > torbenh@xxxxxx 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. > > > > its from cvs, last updated yesterday (03.06.2004). > > 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 ? > > > > 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). > > 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_building.html): "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