Problem with X11 driver

[Andreas Mohr]

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 ! ;-)