http://bugs.winehq.org/show_bug.cgi?id=31442
--- Comment #32 from voidcastr voidcastr@gmail.com 2012-10-05 09:18:30 CDT --- Sooo... just did some research on what's happening in the wined3d/d3d9 code, crawling spammy debug channels (mostly "d3d" and "d3d9"). I'm writing this because I hope that somebody can derive viable information from it -- most of this is far beyond the scope of my knowledge of D3D implementations and/or wine threading issues.
I found that for each new frame, regarded from "d3d:swapchain_gl_present SwapBuffers called, Starting new frame" in the log, the calls seem to be executed in the following order:
d3d:swapchain_gl_present d3d:context_release (d3d:context_acquire) (d3d:device_resource_add) (d3d:wined3d_device_set_viewport) d3d:wined3d_device_get_back_buffer d3d:wined3d_device_get_swapchain d3d:wined3d_swapchain_get_back_buffer
Thereby, parentheses hint to optional calls (i.e. such not occurring for each frame).
On the one hand, when the freeze occurrs, d3d:context_release is the last trace to appear in the log.
On the other hand, if d3d:wined3d_device_get_back_buffer is reached, it results in BeginScene, EndScene and Present methods... and rendering continues just as expected.
d3d:wined3d_device_get_back_buffer is executed by the "d3d9:d3d9_device_GetBackBuffer" API call (see http://msdn.microsoft.com/en-us/library/windows/desktop/bb174379(v=vs.85).as...) which simply seems to not take place anymore under "some condition". As a result, rendering stops and the application appears frozen.
So the above "condition" must be identified... But despite excessive attempts and adding tons of custom traces to the general wined3d or the specific d3d9 implementations, I was not able to find a method blocking/hanging/failing/canceling early anywhere. Especially not one from the above call stack. Furthermore, the problem appears to have nothing to do with wined3d_mutex_lock()/unlock()... in case a deadlock is the reason for the issue discussed here, it's not based on the wined3d_mutex.
Overall, I do not have the impression that wine's d3d9 implementation is failing here -- at least I could not find evidence for that. I rather suspect a more general threading issue. Since the application won't simply choose to stop performing the mentioned API call, something must keep it from doing so. This might or might not be something like the failing attempt of spawning a new thread, a failing notification to an existing thread, etc.
One last thought (but that's only a guess): Considering a more general (threading-related?) scope for the cause of the problem I wondered if it might be some wineserver issue... i.e. if the lack of a useful debug output from wine in the moment of the freeze/crash indicates that we're simply looking in the wrong place. Unfortunately I know absolutely nothing about debugging the wineserver or about how to interpret its output (obtained from explicitly starting it with the -d1/-d2 flags, I assume).
So, unless somebody comes up with some clever idea, I'm giving up for now.