On Thu, Oct 17, 2002 at 10:01:33AM +0200, Till Mossakowski wrote:
Hi,
I have a problem with the X11 driver (it seems), related to bug 1027. When I run my program (Fitch.exe), wine gets stuck. All threads do a WaitForMultipleObjects, the main thread a WaitMessage. And I get an error
err:ntdll:RtlpWaitForCriticalSection section 0x40af4b04 "x11drv_main.c: X11DRV_CritSection" wait timed out, retrying (60 sec) tid=080b8780
I read the FAQ about critical section errors, and it helped my to get the following calling stack:
KERNEL32.DLL.WaitForMultipleObjectsEx+0x16a X11DRV.DLL.MsgWaitForMultipleObjectsEx+0xf3 USER32.DLL.MsgWaitForMultipleObjectsEx+0x14f USER32.DLL.WaitMessage+0x22 WINAWT.DLL.PrintEmbeddedFrame+0x7ca JAVAI.DLL.mmiFrameMethod+0x3625 JAVAI.DLL.mmiFrameMethod+0xb60 COMDLG32.DLL.PrintDlgExW+0x2a2dc0 JPEG.DLL..reloc+0x12e2cb9b *** Invalid address 0xc308c483 (IBMJITC.DLL..reloc+0x1df5f482)
(Indeed, Fitch is written in Java - however, unfortunately it is not possible to run it directly under Linux. I also tried to get diagnostic messages from the Java runtime systems, but it seems that all classes are loaded correctly, and then the error occurs.)
When I set "Synchronous" = "Y" in the x11drv section of config, everything works, but *very* slowly. Sometimes it takes 15 seconds until a mouse click leads to the desired action. I also played with the other x11drv settings in the config file, but without effect.
The documentation says that one should set "Synchronous" = "Y" for debugging purposes. But how proceed then?
This seems to be the classical deadlock problem. If you add synchronous X11 request processing, then the X11 handling is slower, thus it's not activating a lock when some other thread also (tries to) activate(s) a lock. Could you find out which wine process is stuck exactly where by using the standard gdb attach debugging ? gdb wine attach <pid> backtrace
(using current CVS, of course...)
The WINAWT.DLL.PrintEmbeddedFrame+0x7ca and then the WaitMessage could mean that it's trying to print something and then probably Wine does some WaitMessage and gets stuck as some other thread is already holding the X11 lock and can't proceed for some other reason (since it's trying to enter a different lock already established by our thread ?).
Should be rather useful to get this deadlock nailed...
Iff WaitMessage() indeed gets called by Wine and not the program itself, then it's either in windows/win.c or controls/menu.c (maybe add some debug traces there to confirm this invocation).
Good luck ! ;-)