On Thu, 4 Dec 2003 15:59:51 -0600, you wrote:
Log message: Initialize Xlib threading support to see what it breaks...
Thanks for the warning!
Just about everything here halts after a few minutes:
| err:ntdll:RtlpWaitForCriticalSection section 0x40380db0 "?" wait timed out in thread 000e, blocked by 0000, retrying (60 sec) | err:ntdll:RtlpWaitForCriticalSection section 0x40380db0 "?" wait timed out in thread 000e, blocked by 0000, retrying (60 sec) | err:ntdll:RtlpWaitForCriticalSection section 0x40380db0 "?" wait timed out in thread 000e, blocked by 0000, retrying (60 sec) | err:ntdll:RtlpWaitForCriticalSection section 0x40380db0 "?" wait timed out in thread 000e, blocked by 0000, retrying (60 sec) | err:ntdll:RtlpWaitForCriticalSection section 0x40380db0 "?" wait timed out in thread 000e, blocked by 0000, retrying (60 sec)
The easiest way to reproduce it here is switching to another workspace and back again.
After reversing the patch everything is as stable as before.
Debian unstable, glibc 2.3.2 on standard kernel 2.4.22 - no nptl - and xfree86 4.2.1.
Rein.
On Fri, 2003-12-05 at 10:05, Rein Klazes wrote:
On Thu, 4 Dec 2003 15:59:51 -0600, you wrote:
Log message: Initialize Xlib threading support to see what it breaks...
There is a known deadlock in libXi:
http://bugs.xfree86.org/show_bug.cgi?id=260
A fix has been committed to XFree CVS, however it's only available in 4.3 builds when applied by the distro vendor. I thought Debian had also applied it, but it's possible that because you're using XFree 4.2 you are hitting this bug.
Certainly a backtrace of the deadlock would be interesting, if it is the Xi bug it'll look like this:
#0 0x0f04e044 in sigsuspend () from /lib/libc.so.6 #1 0x0f17cadc in __pthread_wait_for_restart_signal () from /lib/libpthread.so.0 #2 0x0f17ec3c in __pthread_alt_lock () from /lib/libpthread.so.0 #3 0x0f17b02c in pthread_mutex_lock () from /lib/libpthread.so.0 #4 0x0ef7e700 in _XLockDisplay (dpy=0x10056640) at locking.c:478 #5 0x0edf2238 in XGetExtensionVersion (dpy=0x10056640, name=0xedf5a18 "XInputExtension") at XGetVers.c:108 #6 0x0edf4dfc in _XiCheckExtInit (dpy=0x10056640, version_index=1) at XExtInt.c:198 #7 0x0edf3004 in XListInputDevices (dpy=0x10056640, ndevices=0x7ffff67c) at XListDev.c:85
thanks -mike
On Fri, 05 Dec 2003 11:12:55 +0000, you wrote:
Certainly a backtrace of the deadlock would be interesting, if it is the Xi bug it'll look like this:
#0 0x0f04e044 in sigsuspend () from /lib/libc.so.6 #1 0x0f17cadc in __pthread_wait_for_restart_signal () from /lib/libpthread.so.0 #2 0x0f17ec3c in __pthread_alt_lock () from /lib/libpthread.so.0 #3 0x0f17b02c in pthread_mutex_lock () from /lib/libpthread.so.0 #4 0x0ef7e700 in _XLockDisplay (dpy=0x10056640) at locking.c:478 #5 0x0edf2238 in XGetExtensionVersion (dpy=0x10056640, name=0xedf5a18 "XInputExtension") at XGetVers.c:108 #6 0x0edf4dfc in _XiCheckExtInit (dpy=0x10056640, version_index=1) at XExtInt.c:198 #7 0x0edf3004 in XListInputDevices (dpy=0x10056640, ndevices=0x7ffff67c) at XListDev.c:85
| (gdb) bt | #0 0x4010e8ab in read () from /lib/libc.so.6 | #1 0x4020a448 in __JCR_LIST__ () from /usr/local/lib/wine/ntdll.dll.so | #2 0xffffffe0 in ?? () | #3 0x401ee2b2 in wait_reply (cookie=0x406cf6c4) at ../../include/winnt.h:1524 | #4 0x401ee5d2 in NTDLL_wait_for_multiple_objects (count=1, handles=0x406cf794, flags=12, timeout=0x406cf7c0) | at sync.c:585 | #5 0x401ee676 in NtWaitForMultipleObjects (count=12, handles=0x406cf7c0, wait_all=2066163, alertable=0 '\0', | timeout=0x401f870e) at sync.c:603 | #6 0x406cf794 in ?? () | #7 0x0000000c in ?? () | #8 0x406cf7c0 in ?? () | #9 0x001f86f3 in pe_load.0 () | Cannot access memory at address 0x118000
Not the same thing, even not a lot of X in it. What I did was starting the program; wait for the deadlock messages; start gdb; attach the pid of the single wine thread; get the back trace. I hope that is correct.
More suggestions what I can try are welcome.
Rein.
On Fri, 2003-12-05 at 12:07, Rein Klazes wrote:
Not the same thing, even not a lot of X in it. What I did was starting the program; wait for the deadlock messages; start gdb; attach the pid of the single wine thread; get the back trace. I hope that is correct.
Well, ideally you'd start winedbg, walk the process list "walk process" and attach, then get a backtrace of the thread that has blocked and the thread that is blocking, by doing (for instance) "bt 0x13" if thread 13 was identified in the message.
ie you should end up with two backtraces
thanks -mike
On Fri, 05 Dec 2003 13:54:02 +0000, you wrote:
On Fri, 2003-12-05 at 12:07, Rein Klazes wrote:
Not the same thing, even not a lot of X in it. What I did was starting the program; wait for the deadlock messages; start gdb; attach the pid of the single wine thread; get the back trace. I hope that is correct.
Well, ideally you'd start winedbg, walk the process list "walk process" and attach, then get a backtrace of the thread that has blocked and the thread that is blocking, by doing (for instance) "bt 0x13" if thread 13 was identified in the message.
ie you should end up with two backtraces
There is only one thread which manages to deadlock itself somehow. That was also indicated by the message ("wait timed out in thread 0010, blocked by 0000").
With winedbg I get for that thread:
| Backtrace: | =>0 0x4010e888 (NTDLL.DLL.memcpy+0x51fc8) (ebp=40019c48) | 1 0x401ee5d2 (NTDLL.DLL.ZwSetTimerResolution+0x452 in NTDLL.DLL) (ebp=40019cf8) | 2 0x401ecb1c (NTDLL.DLL.wine_server_release_fd+0x15fc in NTDLL.DLL) (ebp=40019d1c) | 3 0x4006e498 (NTDLL.DLL.toupper+0x6208) (ebp=406cf85c) | 4 0x401ee5d2 (NTDLL.DLL.ZwSetTimerResolution+0x452 in NTDLL.DLL) (ebp=406cf90c) | 5 0x401ee676 (NTDLL.DLL.NtWaitForMultipleObjects+0x66 in NTDLL.DLL) (ebp=406cf934) | 6 0x401ee6cc (NTDLL.DLL.NtWaitForSingleObject+0x3c in NTDLL.DLL) (ebp=406cf954) | 7 0x401cecd2 (NTDLL.DLL.RtlpWaitForCriticalSection+0x112 in NTDLL.DLL) (ebp=406cf9f0) | 8 0x401cef6f (NTDLL.DLL.RtlEnterCriticalSection+0x3f in NTDLL.DLL) (ebp=406cfa04) | 9 0x404e6289 (KERNEL32.DLL.CloseProfileUserMapping+0x3d9 in KERNEL32.DLL) (ebp=406cfa18) | 10 0x001127ee (_end+0x59e) (ebp=406cfa24) | 11 0x40d769ea (X11DRV.DLL..data+0x799ea) (ebp=406cfa44) | 12 0x40d43799 (X11DRV.DLL..data+0x46799) (ebp=406cfaa4) | 13 0x40cc7320 (X11DRV.DLL.InitKeyboard+0x90 in X11DRV.DLL) (ebp=406cfb64) | 14 0x40cc7f8a (X11DRV.DLL.ActivateKeyboardLayout+0xaa in X11DRV.DLL) (ebp=406cfb84) | 15 0x40cc0224 (X11DRV.DLL.MsgWaitForMultipleObjectsEx+0x474 in X11DRV.DLL) (ebp=406cfbf8) | 16 0x40cbfd90 (X11DRV.DLL.GetDIBColorTable+0x8190 in X11DRV.DLL) (ebp=406cfc78) | 17 0x40cbfecd (X11DRV.DLL.MsgWaitForMultipleObjectsEx+0x11d in X11DRV.DLL) (ebp=406cfdb0) | 18 0x408d3ad6 (USER32.DLL.GetMessageW+0x1f6 in USER32.DLL) (ebp=406cfe68) | 19 0x408d3bc7 (USER32.DLL.GetMessageA+0x37 in USER32.DLL) (ebp=406cfe88) | 20 0x00402142 (notepad.exe.EntryPoint+0x1076 in notepad.exe) (ebp=406cfec0) | 21 0x00401140 (notepad.exe.EntryPoint+0x74 in notepad.exe) (ebp=406cff20) | 22 0x404dd136 (KERNEL32.DLL.SetThreadExecutionState+0x1a86 in KERNEL32.DLL) (ebp=406cfff4) | 23 0x400316b1 (notepad.exe..reloc+0x3fc256b1) (ebp=00000000) |
Using another app, notepad, then the previous post. Because the gdb back trace is slightly different, here is that as well: (gdb) bt | #0 0x4010e888 in read () from /lib/libc.so.6 | #1 0x4020a448 in __JCR_LIST__ () from /usr/local/lib/wine/ntdll.dll.so | #2 0x401ee2b2 in wait_reply (cookie=0x40019c78) at ../../include/winnt.h:1524 | #3 0x401ee5d2 in NTDLL_wait_for_multiple_objects (count=0, handles=0x0, flags=8, timeout=0x40019d10) at sync.c:585 | #4 0x401ecb1c in usr1_handler (__signal=10, __context= | {sc_gs = 135, __gsh = 0, sc_fs = 4103, __fsh = 0, sc_es = 43, __esh = 0, sc_ds = 43, __dsh = 49168, sc_edi = 1080883272, sc_esi = 1073840128, sc_ebp = 1080883292, sc_esp = 1080883248, sc_ebx = 7, sc_edx = 8, sc_ecx = 1080883272, sc_eax = 3, sc_trapno = 0, sc_err = 0, sc_eip = 1074849926, sc_cs = 35, __csh = 0, sc_eflags = 2097734, esp_at_signal = 1080883248, sc_ss = 43, __ssh = 0, i387 = 1073847680, oldmask = 2147483648, cr2 = 0}) at signal_i386.c:1123 | #5 <signal handler called> | #6 0x4010e886 in read () from /lib/libc.so.6 | #7 0x4020a448 in __JCR_LIST__ () from /usr/local/lib/wine/ntdll.dll.so | #8 0x401ee2b2 in wait_reply (cookie=0x406cf88c) at ../../include/winnt.h:1524 | #9 0x401ee5d2 in NTDLL_wait_for_multiple_objects (count=1, handles=0x406cf95c, flags=12, timeout=0x406cf988) | at sync.c:585 | #10 0x401ee676 in NtWaitForMultipleObjects (count=12, handles=0x406cf988, wait_all=2066163, alertable=0 '\0', | timeout=0x401f870e) at sync.c:603 | #11 0x406cf95c in ?? () | #12 0x0000000c in ?? () | #13 0x406cf988 in ?? () | #14 0x001f86f3 in pe_load.0 () | Cannot access memory at address 0x118000
Rein.
-
Mike Hearn -
Rein Klazes