I have a strange crash in thread creation with a program called little fighter II (Which is downloadable off the internet) LF2 Spawns a Thread in User_DirectDrawSurface_Construct (below) and when created the thread creation call crashes in a mutex_lock. Strange thing is the same thread creation calll in eudora3.2 succeeds although there the thread is created to service Asychronous Winsock calls. In the eudora case the Thread is created much later, after the window is up and dispalyed.
Can anyone hazard a guess as to what is happening here ? I am at a loss to explain why the same call should succeed in one place and fall over in another
See below for a partial debug session transcript of the code leading up to the segv fault the program will fall over during the call to _lwp_create.
Bob...
The program being debugged has been started already. Start it from the beginning? (y or n) y Starting program: /export/home/local/bin/wine ./lf2 Setting Signal Handlers err:font:ReadFontDir Can't open directory "/usr2/robert/c/windows/Fonts" x11drv: Warning: $DISPLAY variable ignored, using ':0.0' specified in config file fixme:ddraw:Main_DirectDraw_SetCooperativeLevel (dd5c9438)->(00010022,00000008)
Breakpoint 1, SYSDEPS_SpawnThread (teb=0xdc043000) at ../../scheduler/sysdeps.c:204 204 fprintf(stderr,"Starting New Thread Via thr_create stack base = %lx size =%d\n",teb->stack_base, (char *)teb->stack_top - ( char *)teb->stack_base); (gdb) bt #0 SYSDEPS_SpawnThread (teb=0xdc043000) at ../../scheduler/sysdeps.c:204 #1 0xddb07fad in CreateThread (sa=0x0, stack=0, start=0xdcf0e50c <User_update_thread>, param=0xdd5c9bd0, flags=0, id=0x0) at ../../scheduler/thread.c:289 #2 0xdcf0de1b in User_DirectDrawSurface_Construct (This=0xdd5c9bd0, pDD=0xdd5c9438, pDDSD=0xdd522cbc) at dsurface/user.c:101 #3 0xdcf0decc in User_DirectDrawSurface_Create (pDD=0xdd5c9438, pDDSD=0xdd522cbc, ppSurf=0xdd522d84, pUnkOuter=0x0) at dsurface/user.c:140 #4 0xdcf02ae1 in HAL_DirectDraw_create_primary (This=0xdd5c9438, pDDSD=0xdd522cbc, ppSurf=0xdd522d84, pUnkOuter=0x0) at ddraw/hal.c:446 #5 0xdcf03bc2 in create_primary (This=0xdd5c9438, pDDSD=0xdd522dac, ppSurf=0xdd522d84, pUnkOuter=0x0) at ddraw/main.c:473 #6 0xdcf03f74 in Main_DirectDraw_CreateSurface (iface=0xdd5c9438, pDDSD=0xdd522dac, ppSurf=0xdd522d84, pUnkOuter=0x0) at ddraw/main.c:593 #7 0xdcf058cb in IDirectDrawImpl_CreateSurface (This=0xdd5c9444, pSDesc=0xdd522dac, ppSurface=0x44a854, pUnkOuter=0x0) at ddraw/thunks.c:207 #8 0x00401216 in ?? () #9 0xddb03aec in start_process () at ../../scheduler/process.c:455 #10 0xddb06f0e in call_on_thread_stack (func=0xddb03908) at ../../scheduler/sysdeps.c:124 (gdb) up #1 0xddb07fad in CreateThread (sa=0x0, stack=0, start=0xdcf0e50c <User_update_thread>, param=0xdd5c9bd0, flags=0, id=0x0) at ../../scheduler/thread.c:289 289 if (SYSDEPS_SpawnThread( teb ) == -1) (gdb) list 284 teb->entry_arg = param; 285 teb->startup = THREAD_Start; 286 teb->htask16 = GetCurrentTask(); 287 288 if (id) *id = tid; 289 if (SYSDEPS_SpawnThread( teb ) == -1) 290 { 291 CloseHandle( handle ); 292 close( request_pipe[1] ); 293 THREAD_FreeTEB( teb ); (gdb) print teb $1 = (TEB *) 0xdc043000 (gdb) print *teb $2 = {except = 0xffffffff, stack_top = 0xdc043000, stack_low = 0xdbe20000, htask16 = 279, stack_sel = 0, fiber = 0x0, user_ptr = 0, self = 0xdc043000, tibflags = 1, mutex_count = 0, pid = 0, tid = 10, queue = 0, pad1 = 0, tls_ptr = 0x0, Peb = 0xddb78d40, flags = 0, exit_code = 259, teb_sel = 423, emu_sel = 0, unknown1 = 0, unknown2 = 0, startup = 0xddb07de8 <THREAD_Start>, thread_errno = 0, thread_h_errno = 0, signal_stack = 0xdbe21000, exit_stack = 0x0, emu_data = 0x0, last_error = 0, debug_cb = 0x0, debug_thread = 0, pcontext = 0x0, cur_stack = 0, ThunkConnect = 0, NegStackBase = 0, current_ss = 0, pad2 = 0, ss_table = 0x0, thunk_ss = 0, pad3 = 0, pad4 = {0 <repeats 15 times>}, CurrentLocale = 0, pad5 = {0 <repeats 48 times>}, delta_priority = 0, unknown4 = {0, 0, 0, 0, 0, 0, 0}, create_data = 0x0, suspend_count = 0, entry_point = 0xdcf0e50c, entry_arg = 0xdd5c9bd0, unknown5 = {0, 0, 0, 0}, sys_count = {0, 0, 0, 0}, sys_mutex = {0x0, 0x0, 0x0, 0x0}, unknown6 = {0, 0, 0, 0, 0}, code_page = 0, unused = {0, 0}, gs_sel = 0, request_fd = 14, reply_fd = -1, wait_fd = {-1, -1}, debug_info = 0xdc044000, pthread_data = 0x0, pending_list = 0x0, driver_data = 0x0, dpmi_vif = 0, vm86_pending = 0, vm86_ptr = 0x0, pad6 = {0 <repeats 624 times>}, StaticUnicodeString = {Length = 0, MaximumLength = 522, Buffer = 0xdc043c00}, StaticUnicodeBuffer = {0 <repeats 261 times>}, stack_base = 0xdbe20000, tls_array = {0x0 <repeats 64 times>}, pad8 = {0, 0, 0}, ReservedForNtRpc = 0x0, pad9 = { 0 <repeats 24 times>}, ErrorInfo = 0x0} (gdb) step Starting New Thread Via thr_create stack base = dbe20000 size =2240512 282 _lwp_makecontext( &context, (void(*)(void *))SYSDEPS_StartThread, teb, (gdb) 284 sigprocmask(SIG_SETMASK, NULL, &context.uc_sigmask); (gdb) 285 err=_lwp_create( &context, LWP_DETACHED, &new_lwp ) ; (gdb) print context $3 = {uc_flags = 4, uc_link = 0x50, uc_sigmask = {__sigbits = {1, 0, 0, 0}}, uc_stack = {ss_sp = 0x0, ss_size = 0, ss_flags = 0}, uc_mcontext = {gregs = {0, 143, 31, 31, 0, 0, -603705352, 9, -581817680, -593636687, 9, -581817668, 32, 0, -575639696, 23, -577633087, -603705360, 31}, fpregs = {fp_reg_set = {fpchip_state = {state = {-581133360, 0, -581817304, -584563419, 0, 0, 0, 0, -576773248, -575357312, -581817576, -581817562, -581817772, -575738902, -576456548, -593636687, 9, -581817568, 32, 0, -577515520, -577924375, -577515520, -581817768, -577997369, 11, -576243124}, status = -581817728}, fp_emul_space = { fp_emul = "Ð\233\Ý\0\0\0\0(,RÝ%E(Ý", '\0' <repeats 16 times>, "\200#\237Ý\200¾´Ý\030+RÝ&+RÝT*RÝêë®Ý\234ø£Ý±Ò\235Ü\t\0\0\0 + RÝ \0\0\0\0\0\0\0\0Ð\223Ýé\222\215Ý\0Ð\223ÝX*RÝÇu\214Ý\v\0\0\0L:§Ý\200*RÝÿâ\214Ý\016&²ÝÈ-\224Ý\0Ð\223Ý`Ý\a\bÿâ\214Ý\020Þ\a\b\0\0\0\0\2 24\024\224Ý\0\0\0\0\030Þ\a\b\0Ð\223Ý\234*RÝ{ú\221Ý\210\024\224Ý\0Ð\223Ý°*RÝGÝ\214Ý\026ä°ÝÁä°Ý\001\0\0\0~\e²Ý;ß\a\bW\0"..., fp_epad = "\a\b"}, f_fpregs = {-581133360, 0, -581817304, -584563419, 0, 0, 0, 0, -576773248, -575357312, -581817576, -581817562, -581817772, -575738902, -576456548, -593636687, 9, -581817568, 32, 0, -577515520, -577924375, -577515520, -581817768, -577997369, 11, -576243124, -581817728, -577969409, -575527410, -577491512, -577515520, 134733152, -577969409, 134733328, 0, -577497964, 0, 134733336, -577515520, -581817700, -577635717, -577497976, -577515520, -581817680, -577970873, -575609834, -575609663, 1, -575530114, 134733627, 87, 1, 87, -575322962, 1465002724, -575357312, 134733628, 4096, -581817592, -575525247, 134733336}}, f_wregs = {-604889088, 4096, 87, -604889088, 134733336, 64, -575357312, -581817488, -605945856, -581817556, -575708909, -1, -581817544, -581817540, 320, -581817488, -575357312, -581817488, -581817524, -575708957, -1, -604889088, 4096, 320, -581817488, -575357312, -581817472, -575636289, -604889088, 1, 320, -581817488, 8192}}}, uc_filler = {-605937664, 2248704, 64, -575357312, 10}}
Can anyone hazard a guess as to what is happening here ? I am at a loss to explain why the same call should succeed in one place and fall over in another
NPTL wierdness? I've noticed that if I use an NPTL enabled glibc with a non-NPTL kernel, all kinds of Wrong Things happen, unexplained thread crashes, deadlocks etc that disappear when using an NPTL kernel. Apps that worked before, don't now etc etc.
I doubt this is your problem as before you said you were using gcc 2.95, ie not red hat 9, but it might be worth investigating....
On Monday 23 June 2003 00:49, Mike Hearn wrote:
Can anyone hazard a guess as to what is happening here ? I am at a loss to explain why the same call should succeed in one place and fall over in another
NPTL wierdness? I've noticed that if I use an NPTL enabled glibc with a non-NPTL kernel, all kinds of Wrong Things happen, unexplained thread crashes, deadlocks etc that disappear when using an NPTL kernel. Apps that worked before, don't now etc etc.
I doubt this is your problem as before you said you were using gcc 2.95, ie not red hat 9, but it might be worth investigating....
Actually, my Wine is compiled with gcc 3.2,2 and is running under Solaris and used Solaris (IE SysV lwps for threads) . What I am after is just some suggestions because I am out of ideas at the moment. This problem just doesn't make sense.