[Bug 27406] Red Faction deadlock on start

[wine-bugs at winehq.org]

http://bugs.winehq.org/show_bug.cgi?id=27406

--- Comment #1 from Piotr Pawlow <pp at siedziba.pl> 2011-06-06 17:52:04 CDT ---
Created an attachment (id=35049)
 --> (http://bugs.winehq.org/attachment.cgi?id=35049)
d3d+message+tid trace

This is how I understand what happens:

There are 2 threads involved: thread 0020 manages the window, and thread 0009
does the D3D stuff.

Thread 0009:
- calls CreateDevice with hFocusWindow being the window from the other thread
- wined3d hooks its wndproc to the window (not shown in the trace, as
wined3d_register_window function has no TRACE call)
- wined3d_device_create calls wined3d_device_acquire_focus_window with wined3d
mutex held
- wined3d_device_acquire_focus_window calls SetWindowPos
- SetWindowPos sends WM_WINDOWPOSCHANGING message to the other thread

Thread 0020:
- the message gets passed to wined3d_wndproc
- wined3d_wndproc tries to acquire the mutex, which is held by the other
thread, which in turn is waiting for the message to get processed == deadlock.

So, the solution seems to be either:
- never call any API function that may send a message while holding the mutex
or
- somehow get rid of the mutex in the wined3d_wndproc

-- 
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
Do not reply to this email, post in Bugzilla using the
above URL to reply.
------- You are receiving this mail because: -------
You are watching all bug changes.