Deadlock?

Mike Hearn mike at theoretic.com
Thu Oct 16 03:51:08 CDT 2003


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?




More information about the wine-devel mailing list