[Bug 31442] Guild Wars 2 freezes on text input fields

wine-bugs at winehq.org wine-bugs at winehq.org
Fri Oct 5 09:18:30 CDT 2012


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

--- Comment #32 from voidcastr <voidcastr at 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).aspx)
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.

-- 
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.



More information about the wine-bugs mailing list