I got this from running Panzer General 3 (which you can get for free at http://www.the-underdogs.org):
err:ntdll:RtlpWaitForCriticalSection section 0x40969e80 "../../objects/gdiobj.c: GDI_level" wait timed out in thread 0009, blocked by 0015, retrying (60 sec) err:ntdll:RtlpWaitForCriticalSection section 0x40f227a0 "x11drv_main.c: X11DRV_CritSection" wait timed out in thread 0015, blocked by 0009, retrying (60 sec)
Thread 9 blocked by 15 and thread 15 blocked by 9
Can someone help me how to find out, if it's an application error or a wine error? I used wine-cvs 14.Oct.2003
thx mIc
...und dann war da noch der Statistiker, der in einem Fluß ertrank, der im Durchschnitt nur 10 cm tief war.
Michael Sauer sauer@okolni.de writes:
I got this from running Panzer General 3 (which you can get for free at http://www.the-underdogs.org):
err:ntdll:RtlpWaitForCriticalSection section 0x40969e80 "../../objects/gdiobj.c: GDI_level" wait timed out in thread 0009, blocked by 0015, retrying (60 sec) err:ntdll:RtlpWaitForCriticalSection section 0x40f227a0 "x11drv_main.c: X11DRV_CritSection" wait timed out in thread 0015, blocked by 0009, retrying (60 sec)
Thread 9 blocked by 15 and thread 15 blocked by 9
Can someone help me how to find out, if it's an application error or a wine error?
It's a wine bug, someone is calling GDI functions while holding the X11 lock. A backtrace or a +relay trace should tell you which function is the culprit.
err:ntdll:RtlpWaitForCriticalSection section 0x40969e80 "../../objects/gdiobj.c: GDI_level" wait timed out in thread 0009, blocked by 0015, retrying (60 sec) err:ntdll:RtlpWaitForCriticalSection section 0x40f227a0 "x11drv_main.c: X11DRV_CritSection" wait timed out in thread 0015, blocked by 0009, retrying (60 sec)
It's a wine bug, someone is calling GDI functions while holding the X11 lock.
And it's a race condition, it doesn't happen everytime i run PQ3.exe (although it happens almost 99%, got 1 run so far with PQ3.exe running normally).
I looked around in source (took me some time to understand it)
A backtrace or a +relay trace should tell you which function is the culprit.
The +relay traces are different most runs (depends on my load or how many printf's i put into wine source to find interesting places). Anyhow, there's one analogy between all the traces: the last function thread No'9 calls and does not return is always GDI_GetObjPtr (which i assume is the one defined in objects/gdiobj.c)
Anyhow, the last function thread No'15 calls varies
So, i cannot find the specific position, what to do now?
0015:Call gdi32.DIB_CreateDIBSection(00002e1c,4bd4c650,00000000,4043ef60,00000000,4f430000,00000080) ret=40afd02c 0015:Call x11drv.CreateDIBSection(4bd4c690,4bd4c650,00000000,4043ef60,00000000,4f430000,00000080) ret=4093160e 0015:Call gdi32.CreateDIBitmap(00002e1c,4bd4c650,00000000,00000000,4bd4c650,00000000) ret=40eddcd6 0015:Call x11drv.GetDeviceCaps(4bd4c690,0000000c) ret=4092e466 0015:Ret x11drv.GetDeviceCaps() retval=00000010 ret=4092e466 0015:Call x11drv.GetDeviceCaps(4bd4c690,0000000e) ret=4092e466 0015:Ret x11drv.GetDeviceCaps() retval=00000001 ret=4092e466 0009:Call user32.SetRect(407928e4,00000000,00000000,000001a6,00000011) ret=40cd4ee7 0009:Ret user32.SetRect() retval=00000001 ret=40cd4ee7 0009:Call gdi32.GDI_GetObjPtr(00002ce8,00004f4b) ret=40edcb3e 0015:Call x11drv.CreateBitmap(4bd4c690,00002e20) ret=4092a50d 0015:Call gdi32.GDI_GetObjPtr(00002e20,00004f4b) ret=40ed08fe 0015:Ret gdi32.GDI_GetObjPtr() retval=4c1ee610 ret=40ed08fe 0015:Call gdi32.GetStockObject(00000012) ret=40ed098c 0015:Ret gdi32.GetStockObject() retval=00000048 ret=40ed098c
mIc
...und dann war da noch der Statistiker, der in einem Fluß ertrank, der im Durchschnitt nur 10 cm tief war.
Michael Sauer sauer@okolni.de writes:
The +relay traces are different most runs (depends on my load or how many printf's i put into wine source to find interesting places). Anyhow, there's one analogy between all the traces: the last function thread No'9 calls and does not return is always GDI_GetObjPtr (which i assume is the one defined in objects/gdiobj.c)
Anyhow, the last function thread No'15 calls varies
So, i cannot find the specific position, what to do now?
Once it is deadlocked, you should attach to the various threads with gdb or winedbg and do a backtrace.
On Wed, 2003-10-15 at 01:38, Alexandre Julliard wrote:
So, i cannot find the specific position, what to do now?
Once it is deadlocked, you should attach to the various threads with gdb or winedbg and do a backtrace.
I might as well point out (as I didn't find this intuitive when I was learning) that you do that like this:
1) Open up a new terminal window 2) Run winedbg 3) "walk process" 4) Locate the win32 process id of the program that has deadlocked 5) "attach X" where X is the pid 6) "bt 0x9" gives you a backtrace of thread 9 7) "bt 0x15" gives you a backtrace of thread 15 etc....
Then you can see what path the code took before it hit the locks.
On Wed, 15 Oct 2003, Mike Hearn wrote:
I might as well point out (as I didn't find this intuitive when I was learning) that you do that like this:
- Open up a new terminal window
- Run winedbg
- "walk process"
- Locate the win32 process id of the program that has deadlocked
- "attach X" where X is the pid
- "bt 0x9" gives you a backtrace of thread 9
- "bt 0x15" gives you a backtrace of thread 15 etc....
ok did that (and attached at bottom of mail) and it helped a lot. But i still don't know, where the specific error lies: thread 0x3c called IDirectDraw4Impl_CreateSurface which lead over X11DRV_DeleteDC to the tsx11_lock thread 0x2s called VIRTUAL_HandleFault which lad over GDI_GetObjPtr to the _EnterSysLevel lock thing But i don't see the typical deadlock situation there (e.g. semaphore s,t Thread1 : lock(s) lock(t) Thread2 : lock(t) lock(s) )
Anyhow, this is perhaps the interesting part of thread 0x2f:
12 0x401e43ad (VIRTUAL_HandleFault+0xcd(addr=0x4eef0000) [virtual.c:829] in ntdll.dll.so) (ebp=406909b4) 13 0x401dda53 (.L63+0xb [signal_i386.c] in ntdll.dll.so) (ebp=40690a2c) 14 0x401ddf61 (segv_handler+0x41(__signal=0xb, __context=0x14d7) [signal_i386.c:1058] in ntdll.dll.so) (ebp=40690d1c) 15 0x400645f8 (NTDLL.DLL.toupper+0x6298 in libc.so.6) (ebp=407a1dfc)
is it possible, that the thread produced a segfault while holding tsx11 lock, then the fault handler galled a GDI function?
mIc
err:ntdll:RtlpWaitForCriticalSection section 0x40f257a0 "x11drv_main.c: X11DRV_C ritSection" wait timed out in thread 003c, blocked by 002f, retrying (60 sec) err:ntdll:RtlpWaitForCriticalSection section 0x40979e80 "../../objects/gdiobj.c: GDI_level" wait timed out in thread 002f, blocked by 003c, retrying (60 sec)
Wine-dbg>walk thread process tid prio 0000002e (D) C:\Spiele\pg3\PG3.exe 0000003c 1 00000038 0 00000037 15 00000034 0 <== 00000032 2 00000031 0 00000030 0 0000002f 0
Wine-dbg>bt 0x2f Backtrace: =>0 0x4010595b (NTDLL.DLL.memcpy+0x5288b in libc.so.6) (ebp=4069038c) 1 0x401dff72 (NTDLL_wait_for_multiple_objects+0x122(count=0x0, handles=0x0, flags=0x8, timeout=0x40690448) [sync.c:584] in ntdll.dll.so) (ebp=40690430) 2 0x401de23c (usr1_handler+0x4c(__signal=0xa, __context=0x14d7) [signal_i386.c:1162] in ntdll.dll.so) (ebp=40690454) 3 0x400645f8 (NTDLL.DLL.toupper+0x6298 in libc.so.6) (ebp=40690764) 4 0x401dff72 (NTDLL_wait_for_multiple_objects+0x122(count=0x1, handles=0x40690858, flags=0xc, timeout=0x40690884) [sync.c:584] in ntdll.dll.so) (ebp=40690808) 5 0x401dffe6 (NTDLL.DLL.NtWaitForMultipleObjects+0x66 in ntdll.dll.so) (ebp=40690830) 6 0x401e003c (NtWaitForSingleObject+0x3c(handle=0x10c, alertable=0x0, timeout=0x40690884) [sync.c:611] in ntdll.dll.so) (ebp=40690850) 7 0x401c0f02 (RtlpWaitForCriticalSection+0x112(crit=0x40979e80) [critsection.c:193] in ntdll.dll.so) (ebp=406908ec) 8 0x401c119f (RtlEnterCriticalSection+0x3f(crit=0x40979e80) [critsection.c:255] in ntdll.dll.so) (ebp=40690900) 9 0x404e645c (_EnterSysLevel+0x6c(lock=0x40979e80) [syslevel.c:112] in kernel32.dll.so) (ebp=40690934) 10 0x4094c76b (GDI_GetObjPtr+0x2b(handle=0x2c74, magic=0x4f4b) [gdiobj.c:809] in gdi32.dll.so) (ebp=40690968) 11 0x40edfb3e (X11DRV_DIB_FaultHandler+0x2e(res=0x2c74, addr=0x4eef0000) [dib.c:5284] in x11drv.dll.so) (ebp=40690988) 12 0x401e43ad (VIRTUAL_HandleFault+0xcd(addr=0x4eef0000) [virtual.c:829] in ntdll.dll.so) (ebp=406909b4) 13 0x401dda53 (.L63+0xb [signal_i386.c] in ntdll.dll.so) (ebp=40690a2c) 14 0x401ddf61 (segv_handler+0x41(__signal=0xb, __context=0x14d7) [signal_i386.c:1058] in ntdll.dll.so) (ebp=40690d1c) 15 0x400645f8 (NTDLL.DLL.toupper+0x6298 in libc.so.6) (ebp=407a1dfc) 16 0x40f5bf74 (_end+0x35648 in libGL.so.1) (ebp=00000011)
Wine-dbg>bt 0x3c Backtrace: =>0 0x40064684 (NTDLL.DLL.toupper+0x6324 in libc.so.6) (ebp=4e8f07d4) 1 0x401dc720 (wine_server_call+0x40(req_ptr=0x4e8f0888) [server.c:226] in ntdll.dll.so) (ebp=4e8f0874) 2 0x404abd19 (CONSOLE_GetNumHistoryEntries+0x59 [console.c:65] in kernel32.dll.so) (ebp=4e8f0904) 3 0x404aa06c (CONSOLE_HandleCtrlC+0x1c(sig=0x2) [console.c:1394] in kernel32.dll.so) (ebp=4e8f09e0) 4 0x401de11d (int_handler+0x9d(__signal=0x2, __context=0x14d7) [signal_i386.c:427] in ntdll.dll.so) (ebp=4e8f0d1c) 5 0x400645f8 (NTDLL.DLL.toupper+0x6298 in libc.so.6) (ebp=4ea11dc0) 6 0x401dff72 (NTDLL_wait_for_multiple_objects+0x122(count=0x1, handles=0x4ea11eb4, flags=0xc, timeout=0x4ea11ee0) [sync.c:584] in ntdll.dll.so) (ebp=4ea11e64) 7 0x401dffe6 (NTDLL.DLL.NtWaitForMultipleObjects+0x66 in ntdll.dll.so) (ebp=4ea11e8c) 8 0x401e003c (NtWaitForSingleObject+0x3c(handle=0x108, alertable=0x0, timeout=0x4ea11ee0) [sync.c:611] in ntdll.dll.so) (ebp=4ea11eac) 9 0x401c0f02 (RtlpWaitForCriticalSection+0x112(crit=0x40f257a0) [critsection.c:193] in ntdll.dll.so) (ebp=4ea11f48) 10 0x401c119f (RtlEnterCriticalSection+0x3f(crit=0x40f257a0) [critsection.c:255] in ntdll.dll.so) (ebp=4ea11f5c) 11 0x40f08942 (wine_tsx11_lock+0x22 [x11drv_main.c:159] in x11drv.dll.so) (ebp=4ea11f6c) 12 0x40ee4fd9 (X11DRV_DeleteDC+0x29(physDev=0x4043c290) [init.c:141] in x11drv.dll.so) (ebp=4ea11f88) 13 0x4093e236 (DeleteDC+0x186(hdc=0x2d20) [dc.c:793] in gdi32.dll.so) (ebp=4ea11fbc) 14 0x40b0d039 (create_dib+0x1a9(This=0x40430f90) [dib.c:161] in ddraw.dll.so) (ebp=4ea11ff0) 15 0x40b0d40d (DIB_DirectDrawSurface_Construct+0xdd(This=0x40430f90, pDD=0x40387d18, pDDSD=0x4ea12118) [dib.c:269] in ddraw.dll.so) (ebp=4ea12024) 16 0x40b0d5e8 (DIB_DirectDrawSurface_Create+0x78(pDD=0x40387d18, pDDSD=0x4ea12118, ppSurf=0x4ea12310, pUnkOuter=0x0) [dib.c:300] in ddraw.dll.so) (ebp=4ea12048) 17 0x40b0780a (Main_create_texture+0x3a(This=0x40387d18, pDDSD=0x4ea12118, ppSurf=0x4ea12310, pOuter=0x0, dwMipMapLevel=0x0) [main.c:342] in ddraw.dll.so) (ebp=4ea12064) 18 0x40b07ad6 (create_texture+0x1e6(This=0x40387d18, pDDSD=0x4ea12218, ppSurf=0x4ea12310, pUnkOuter=0x0) [main.c:406] in ddraw.dll.so) (ebp=4ea121a4) 19 0x40b0837e (Main_DirectDraw_CreateSurface+0x19e(iface=0x40387d18, pDDSD=0x4ea12218, ppSurf=0x4ea12310, pUnkOuter=0x0) [main.c:632] in ddraw.dll.so) (ebp=4ea121d8) 20 0x40b0a6d0 (IDirectDraw4Impl_CreateSurface+0x40(This=0x40387d1c, pSDesc=0x4ea12218, ppSurface=0x4ea12310, pUnkOuter=0x0) [thunks.c:262] in ddraw.dll.so) (ebp=4ea121f4) 21 0x100e68bf (PG3RENDR.DLL.EntryPoint+0x10a8f in PG3RENDR.DLL) (ebp=4a6d2470) 22 0x00000004 (ebp=1011c460) 23 0x100eab40 (PG3RENDR.DLL.EntryPoint+0x14d10 in PG3RENDR.DLL) (ebp=100e97e0) 24 0x9090c310 (_end+0x4377c3d0) (ebp=14e528b8) *** Invalid address 0x14e528b8 (PG3RENDR.DLL..reloc+0x4d028b8)
On Wed, 2003-10-15 at 15:30, Michael Sauer wrote:
12 0x401e43ad (VIRTUAL_HandleFault+0xcd(addr=0x4eef0000) [virtual.c:829] in ntdll.dll.so) (ebp=406909b4) 13 0x401dda53 (.L63+0xb [signal_i386.c] in ntdll.dll.so) (ebp=40690a2c) 14 0x401ddf61 (segv_handler+0x41(__signal=0xb, __context=0x14d7) [signal_i386.c:1058] in ntdll.dll.so) (ebp=40690d1c) 15 0x400645f8 (NTDLL.DLL.toupper+0x6298 in libc.so.6) (ebp=407a1dfc)
is it possible, that the thread produced a segfault while holding tsx11 lock, then the fault handler galled a GDI function?
That does look rather wrong, doesn't it? I have a feeling that it is actually intended behaviour - Wine uses trapped access violations to figure out when the X server needs to be flushed with the contents of a DIB - see this part:
11 0x40edfb3e (X11DRV_DIB_FaultHandler+0x2e(res=0x2c74, addr=0x4eef0000) [dib.c:5284] in x11drv.dll.so) (ebp=40690988)
Basically this indicates that the fault is intended, and occurred because an application wrote directly to the memory that held the DIB. So we can ignore this part I think.
4 0x401de11d (int_handler+0x9d(__signal=0x2, __context=0x14d7) [signal_i386.c:427] in ntdll.dll.so) (ebp=4e8f0d1c)
More interesting is this one - you pressed Ctrl-C?
I think you need to find out which thread is holding the X11 lock, because what we have here is:
* Some thread id ?? grabs the X11 lock * Thread 0x3c attempts to delete a device context, so deadlocks on the X11 lock while inside a syslevel * Thread 0x2f writes to a DIB, triggering a fault which is handled by Wine and then we also try to enter the syslevel held by 0x3c, so we deadlock.
The question then is what is the first thread doing?
People who know what they're talking about - is this reading of the entrails a sane one?
- Some thread id ?? grabs the X11 lock
- Thread 0x3c attempts to delete a device context, so deadlocks on the
X11 lock while inside a syslevel
- Thread 0x2f writes to a DIB, triggering a fault which is handled by
Wine and then we also try to enter the syslevel held by 0x3c, so we deadlock.
Hm, anyhow i didn't find the position, with today's compile of cvs-tree the bug seems to be gone.
mIc
...und dann war da noch der Statistiker, der in einem Fluß ertrank, der im Durchschnitt nur 10 cm tief war.
-
Alexandre Julliard -
Michael Sauer -
Mike Hearn