http://bugs.winehq.org/show_bug.cgi?id=31442
Bug #: 31442 Summary: Guild Wars 2 freezes on text input fields Product: Wine Version: 1.5.10 Platform: x86 OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown AssignedTo: wine-bugs@winehq.org ReportedBy: rmlipman@gmail.com Classification: Unclassified
When certain text fields get focus, including the name field in character creation and the chat window, the game freezes.
http://bugs.winehq.org/show_bug.cgi?id=31442
--- Comment #1 from rmlipman@gmail.com 2012-08-10 18:19:48 CDT --- I've seen a few reports from Windows users that might be affected by this, so this might actually be a game bug and not a wine bug.
http://bugs.winehq.org/show_bug.cgi?id=31442
Tom fastumzug@fastmail.fm changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |fastumzug@fastmail.fm
--- Comment #2 from Tom fastumzug@fastmail.fm 2012-08-11 09:09:54 CDT --- Same issue happened here the last stress tests. All input fields are effected. No workaround found :(
http://bugs.winehq.org/show_bug.cgi?id=31442
Sarah wintertanz@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |wintertanz@gmail.com
--- Comment #3 from Sarah wintertanz@gmail.com 2012-08-11 09:45:59 CDT --- To reproduce the bug, try to create a new character. Either click on "skip" to go directly to the screen where you got to name your character, or click through the steps until you reach step 9. If you try to go to step 10 from there, the freeze happens.
This issue is present both with unmodified Wine 1.5.9 and with raw3 patch. I tried changing the Windows version, playing around with Direct3D registry settings and with ingame graphics settings. None of this made any difference.
When the freeze happens, Wine does not register a crash. The game just sits there and needs to be killed manually. There is no crash dump and nothing is logged in the console at the moment of the freeze. No debug information, sorry.
Since the character creation name field is freezing the game, this bug makes it impossible to complete the process. New characters cannot be created. Because of this, I was unable to test if the bug would prevent me from using the ingame chat, but it seems likely that all input fields (including ingame mail) suffer from the same problem.
A few Windows users reported the same problem during the two latest stress tests.
http://bugs.winehq.org/show_bug.cgi?id=31442
cyanpill@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |cyanpill@gmail.com
--- Comment #4 from cyanpill@gmail.com 2012-08-11 22:32:03 CDT --- The bug report window was one text box that worked without problem- it was just plain box. The other have decorations.
http://bugs.winehq.org/show_bug.cgi?id=31442
steve snantel@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |snantel@gmail.com
--- Comment #5 from steve snantel@gmail.com 2012-08-13 13:41:34 CDT --- I had the same problem, when you get to step 9/10 and click next, the game freeze.
If you launch the game in windows, the step 10/10 have a text box where you have to specify your name.
http://bugs.winehq.org/show_bug.cgi?id=31442
--- Comment #6 from rmlipman@gmail.com 2012-08-14 15:33:22 CDT --- Did anyone ever figure this out? If not, the game will be unplayable at release because the name field on character creation is affected by this bug.
http://bugs.winehq.org/show_bug.cgi?id=31442
--- Comment #7 from Sarah wintertanz@gmail.com 2012-08-14 16:32:46 CDT --- The developers are aware of the issue. It would be reasonable to assume that they are trying their best to fix this until release, since the issue seems to affect Windows users as well.
http://bugs.winehq.org/show_bug.cgi?id=31442
--- Comment #8 from Bruno Jesus 00cpxxx@gmail.com 2012-08-14 16:38:12 CDT --- (In reply to comment #7)
The developers are aware of the issue. It would be reasonable to assume that they are trying their best to fix this until release, since the issue seems to affect Windows users as well.
Can you post links to references of windows users being affected? That being true would possibly make this bug invalid.
http://bugs.winehq.org/show_bug.cgi?id=31442
--- Comment #9 from Sarah wintertanz@gmail.com 2012-08-14 16:56:24 CDT --- (In reply to comment #8)
(In reply to comment #7)
The developers are aware of the issue. It would be reasonable to assume that they are trying their best to fix this until release, since the issue seems to affect Windows users as well.
Can you post links to references of windows users being affected? That being true would possibly make this bug invalid.
http://www.guildwars2guru.com/topic/48279-screen-freezes-because-of-chat/ http://www.guildwars2guru.com/topic/48843-any-one-have-freezing-problems-on-... (third post)
There’s also a bug report thread in the Technical Support section of the official forums, but those are currently down (will open again briefly during the stress test tomorrow) and only accessible for pre-purchasers. Still, here is the link for reference: https://forum-en.guildwars2.com/forum/stress/bugs/I-can-t-use-chat-game-free...
Either those are all Wine gamers in disguise, or this is an issue at least partially unrelated to Wine. We still do not know if everyone experiences this problem under Wine, or if it affects only part of the userbase.
http://bugs.winehq.org/show_bug.cgi?id=31442
--- Comment #10 from steve snantel@gmail.com 2012-08-15 14:08:13 CDT --- 15 aug 15:05.
I created a char with windows 7 and launched the game with my linux box after.
I can enter the game without any problems but as soon as I touch the text screen to chat, the game freeze. (no crash, just unresponding.)
Wine 1.5.10 running on Ubuntu 12.04. With an NVIDIA graphic card.
http://bugs.winehq.org/show_bug.cgi?id=31442
--- Comment #11 from rmlipman@gmail.com 2012-08-15 15:36:29 CDT --- A dev posted a workaround for the freezing in the stress test forums. Try adding the command line argument -dx9single.
http://bugs.winehq.org/show_bug.cgi?id=31442
--- Comment #12 from Sarah wintertanz@gmail.com 2012-08-15 15:58:46 CDT --- Confirmed. Passing -dx9single as an argument makes the freezes go away. I can create characters and use the ingame chat without problems.
http://bugs.winehq.org/show_bug.cgi?id=31442
sworddragon2@aol.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |sworddragon2@aol.com
http://bugs.winehq.org/show_bug.cgi?id=31442
Luke Bratch l_bratch@yahoo.co.uk changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |l_bratch@yahoo.co.uk
http://bugs.winehq.org/show_bug.cgi?id=31442
--- Comment #13 from sworddragon2@aol.com 2012-09-27 17:31:18 CDT --- Is the bug for the Windows user completely solved? If yes can somebody test if this bug is still a problem with Wine?
http://bugs.winehq.org/show_bug.cgi?id=31442
--- Comment #14 from cyanpill@gmail.com 2012-09-27 22:37:27 CDT --- (In reply to comment #13)
Is the bug for the Windows user completely solved? If yes can somebody test if this bug is still a problem with Wine?
I haven't heard anything from windows users of this still happening, but I checked to see how performance is without the flag on linux. Still locking up when I try the chatbox, naming character or sending mail. Bug reports and searching on the market place do not cause any issue. I had heard reports of higher fps without the flag, but I didn't see any change there.
Found on post on the forums that could be the same on windows: https://forum-en.guildwars2.com/forum/support/tech/Randomly-can-t-chat-emote...
http://bugs.winehq.org/show_bug.cgi?id=31442
voidcastr voidcastr@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |voidcastr@gmail.com
http://bugs.winehq.org/show_bug.cgi?id=31442
--- Comment #15 from voidcastr voidcastr@gmail.com 2012-10-01 09:40:40 CDT --- Created attachment 41902 --> http://bugs.winehq.org/attachment.cgi?id=41902 startup with -dx9single flag
http://bugs.winehq.org/show_bug.cgi?id=31442
--- Comment #16 from voidcastr voidcastr@gmail.com 2012-10-01 09:41:14 CDT --- Created attachment 41903 --> http://bugs.winehq.org/attachment.cgi?id=41903 startup without -dx9single flag
I just created two GW2 startup logs for a mutual comparison: - first one: with -dx9single flag - second one: without the flag
As you can see, the second one includes several instances of the line "fixme:d3d:wined3d_occlusion_query_ops_get_data 0x398c9598 Wrong thread, returning 1."
These lines are missing in the log created when starting the game with the -dx9single flag. But when doing so, a single line "fixme:d3d:state_zfunc D3DCMP_NOTEQUAL and D3DCMP_EQUAL do not work correctly yet." is present which is not there when omitting the flag.
(Hint: "meld" is a nice GUI tool to compare logs like that.)
I activated no special debug channels -- this is just "wine Gw2.exe &> log.txt".
Any of the above might or might not be related to the cause of the freeze bug we experience when trying to chat or name a character.
http://bugs.winehq.org/show_bug.cgi?id=31442
voidcastr voidcastr@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |hverbeet@gmail.com
http://bugs.winehq.org/show_bug.cgi?id=31442
--- Comment #17 from voidcastr voidcastr@gmail.com 2012-10-01 12:35:48 CDT --- Henri, I added you to the CC list because -- if my git skills don't fail me -- you appear to be one of the authors of the code that *might* be related to the problem discussed here.
---
I identified the origin of the message (as obtained from the log in my previous post) "fixme:d3d:wined3d_occlusion_query_ops_get_data 0x398c9598 Wrong thread, returning 1." as dlls/wined3d/query.c, method static HRESULT wined3d_occlusion_query_ops_get_data(struct wined3d_query *query, void *pData, DWORD dwSize, DWORD flags)
Since the -dx9single flag is suspected to disable multithreaded rendering and the above message (which is only shown when omitting the flag) complains about erroneous threading circumstances, I suspect it to be somewhat related to the freeze crash.
Nevertheless, I don't even know if this fixme is even to be considered critical. I'm really grapsing at straws here since I cannot find a suitable debug channel yielding ANY usable output in the moment the game freezes.
So... I'm open for any suggestions.
http://bugs.winehq.org/show_bug.cgi?id=31442
--- Comment #18 from Henri Verbeet hverbeet@gmail.com 2012-10-01 13:16:06 CDT --- I can't really rule out occlusion queries, but I think it's more likely that this is some variant of bug 31406. A backtrace would probably help.
http://bugs.winehq.org/show_bug.cgi?id=31442
--- Comment #19 from voidcastr voidcastr@gmail.com 2012-10-01 15:02:39 CDT --- You mean a backtrace of the actual crash? That's the problem: The application simply freezes wihout any further output.
Nevertheless, http://bugs.winehq.org/attachment.cgi?id=41903 is a log from the startup to the crash. It was created with wine Gw2.exe &> log.txt using 1.5.14.
I don't know which warn or trace channels to activate... tried a few, but in any case the output was either totally spammy and did't even alter or stop after the freeze, or nothing interesting gets logged (especially not in the moment the application freezes).
Some more notes on what happens when the game freezes: - the process' CPU usage instantly drops from ~148% to 4% - background music is still playing -- however, sounds are not "live" anymore (those caused by other players next to my character cannot be heared) - input is dead, as expected
However, I just found that focussing a text input field for the FIRST time (either when trying to chat ingame or when prompted to enter the name for a new character) causes these two log lines when running the game with the -dx9single argument:
fixme:imm:ImmGetOpenStatus (0x396e55c0): semi-stub fixme:imm:ImmReleaseContext (0x80064, 0x396e55c0): stub
Without the -dx9single flag the application crashes before the above gets logged. However, since these lines can only be observed when running the application with its -dx9single flag, I'm not sure if the lines are present due to the very usage of the flag or if the fact that they are missing when omitting the flag is actually a symptom of the crash.
http://bugs.winehq.org/show_bug.cgi?id=31442
--- Comment #20 from voidcastr voidcastr@gmail.com 2012-10-02 03:18:06 CDT --- (In reply to comment #18)
I can't really rule out occlusion queries, but I think it's more likely that this is some variant of bug 31406. A backtrace would probably help.
Mea culpa... I did not realize that you might have referred to a winedbg backtrace.
I tried to get one but the howto in the wine wiki (wiki.winehq.org/Backtraces) appears to be slightly outdated.
Here's what I've done:
1. start the application with "wine Gw2.exe"
2. open another terminal for "winedbg" -> "info process" -> "attach 0x...". So far so good.
3. then, using "set $!BreakOnFirstChance=0" in winedbg as suggested in the wiki does not work since it complains about a "Syntax Error ($) Unknown option 'BreakOnFirstChance' syntax error"
4. I entered "cont" anyway... but winedbg seems to block there, not showing me another prompt (until I hit Ctrl-C or run "killall Gw2.exe" from another terminal; see below)
From here, I'm not sure if I'm still on the right track and if the backtraces I
obtained this way might be useful at all:
5. I provoked the application freeze
6. winedbg was still blocking, so I hit Ctrl-C and got a backtrace with "bt"
7. if I "killall Gw2.exe" afterwards and winedbg>"bt" again, the backtrace changes
Now, I'm not sure if one of the backtraces represents the actual freeze bug/crash, or if one or both of them are just the reaction to the signal I sent with Ctrl-C or to killing the application, respectively.
Any corrections/comments on my approach? For now, I refrained from posting the above traces here because I don't wanna cause confusion in case they are useless.
(PS: My apologies if these are dumb questions... I'm still new to wine debugging stuff in general.)
http://bugs.winehq.org/show_bug.cgi?id=31442
--- Comment #21 from Henri Verbeet hverbeet@gmail.com 2012-10-02 03:59:01 CDT --- It might be ok. The easiest thing to do is probably to wait for the application to lock up, then start winedbg, and run "bt all".
http://bugs.winehq.org/show_bug.cgi?id=31442
--- Comment #22 from voidcastr voidcastr@gmail.com 2012-10-02 05:03:14 CDT --- Created attachment 41909 --> http://bugs.winehq.org/attachment.cgi?id=41909 backtrace as suggested in post #21
Here you go.
http://bugs.winehq.org/show_bug.cgi?id=31442
--- Comment #23 from Henri Verbeet hverbeet@gmail.com 2012-10-02 05:11:45 CDT --- You seem to be lacking debug symbols, which makes it harder to see what's going on. I don't see either winex11 or wined3d in that backtrace though, so it's probably a different issue than bug 31406.
http://bugs.winehq.org/show_bug.cgi?id=31442
voidcastr voidcastr@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #41909|0 |1 is obsolete| |
--- Comment #24 from voidcastr voidcastr@gmail.com 2012-10-02 05:24:50 CDT --- Created attachment 41910 --> http://bugs.winehq.org/attachment.cgi?id=41910 second try: backtrace as suggested in post #21
Now with debug symbols.
http://bugs.winehq.org/show_bug.cgi?id=31442
voidcastr voidcastr@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #41910|0 |1 is obsolete| |
--- Comment #25 from voidcastr voidcastr@gmail.com 2012-10-02 07:42:33 CDT --- Created attachment 41912 --> http://bugs.winehq.org/attachment.cgi?id=41912 third try: backtrace as suggested in post #21
...now with source code file names and line numbers. I guess that was the kind of backtrace you were looking for.
Compiling wine with CFLAGS=-g did the trick.
http://bugs.winehq.org/show_bug.cgi?id=31442
--- Comment #26 from voidcastr voidcastr@gmail.com 2012-10-03 03:54:14 CDT --- Actually, I don't know exactly for what I should look in the backtrace... I'm not even sure that it contains what we're looking for.
There are so many threads running, and at least one apparently blocks (like waiting forever for some lock) or crashes... but I don't know how to identify either of these scenarios due to not really being familiar with wine's detailed call structure.
All I can tell from the initial observations is that the thread in question (whichever it might be) is not likely to be trapped in some infinity loop because CPU usage basically lowers to almost 0% when the freeze occurs.
In case we are facing a (dead)lock scenario here, and not simply a crashed thread, we won't find anything in the backtrace either, will we? At least it would be quite difficult to see.
http://bugs.winehq.org/show_bug.cgi?id=31442
--- Comment #27 from Henri Verbeet hverbeet@gmail.com 2012-10-03 04:29:28 CDT --- Usually you should see what threads are involved in a deadlock. (I.e. "... wait timed out in thread <tid1> blocked by <tid2>, ..." messages.) There's no mention of d3d9 or wined3d in the backtrace though, so either those aren't involved in the deadlock, or what you're seeing isn't so much a deadlock as the rendering thread just dieing. There's no mention of xcb_wait_for_reply() either, so this is definitely not bug 31406.
http://bugs.winehq.org/show_bug.cgi?id=31442
--- Comment #28 from voidcastr voidcastr@gmail.com 2012-10-03 05:15:34 CDT --- (In reply to comment #27)
Usually you should see what threads are involved in a deadlock. (I.e. "... wait timed out in thread <tid1> blocked by <tid2>, ..." messages.)
Yeah, I also found that here in the meantime: http://wine-wiki.org/index.php/Debugging_Wine
However, I made an observation: According to Wine-dbg's "info process"/"info thread", the number of threads spawned by the application varies depending on the usage of its -dx9single cmdline argument:
With -dx9single: 36 threads Without: 37 threads
(The above thread counts were obtained in the application's non-frozen state in both cases.)
This is not overly surprising and I'm currently trying to associate the threads of both cases with each other, in order to identify the extra thread in the second case and then analyze its trace. Sadly, I don't expect this method to succeed because tids are only partially deterministic and the BTs obtained while the application is not crashed/frozen also tend to vary greatly.
Interestingly, tids are the same after most application startups when NOT using -dx9single, while greatly varying when using the flag -- I actually expected the contrary (more parallel threads usually lead to less deterministic results).
or what you're seeing isn't so much a deadlock as the rendering thread just dieing.
Yep, but I still don't understand why -- if the rendering thread just dies -- it appears to be impossible to get some exception, segfault, ... anything at all.
http://bugs.winehq.org/show_bug.cgi?id=31442
--- Comment #29 from voidcastr voidcastr@gmail.com 2012-10-03 05:24:01 CDT --- The latter point led me to the assumption that the thread is indeed NOT crashing but just waiting forever while not even failing after a timeout. This might be the case because there simply IS no finite timeout. This, in turn, might be related to calls to
NTDLL_wait_for_multiple_objects or NtWaitForMultipleObjects
with timeout=(nil), which can be observed in the backtrace in comment #25
Though, this is just a guess. I don't know the semantics of the above functions' parameters and whether or not passing a nil timeout to them is discouraged, i.e. might cause lock situations.
http://bugs.winehq.org/show_bug.cgi?id=31442
--- Comment #30 from voidcastr voidcastr@gmail.com 2012-10-03 13:06:08 CDT --- After google'ing around a bit (the function seems to be pooly documented) it appears to me that passing 0/NULL/nil-values to it is not likely to cause infinite waiting times.
I'm out of ideas now.
http://bugs.winehq.org/show_bug.cgi?id=31442
--- Comment #31 from voidcastr voidcastr@gmail.com 2012-10-03 13:41:02 CDT --- Ehm... "poorly", I meant -_-
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.
http://bugs.winehq.org/show_bug.cgi?id=31442
--- Comment #33 from Henri Verbeet hverbeet@gmail.com 2012-10-05 10:40:25 CDT --- You'll probably want +seh,+tid as well, and maybe +relay. The first thing you want to figure out is probably if the d3d thread stops because it died (i.e. the last thing you see it do is raising an exception), or because it's waiting for some other thread to do something (in which case the last thing you see would be something like WaitForMultipleObjects()).
http://bugs.winehq.org/show_bug.cgi?id=31442
--- Comment #34 from voidcastr voidcastr@gmail.com 2012-10-07 09:00:49 CDT --- Thanks for the clue, Henri!
+seh does not yield any output in the moment the freeze occurs or afterwards.
As far as I can tell from +tid, there are several threads doing the d3d/9 work, with split tasks: - "002f": deals with resource preparation (CreateTexture, surface operations, ...) - "0038" (/"0044", see below): deals with the actual rendering (swapchain ops, ...)
So, this is basically how GW2's multithreaded (actually: dualthreaded) rendering works... it's the first time we really get a notion of it, as far as I can tell.
Unsurprisingly, "002f" does all the initialization work and writes hundreds of thousands of lines to the log before "0038" is called for the first time.
Nevertheless there is a remarkable aspect about the second thread: It changes after some time, i.e. the ID of the tread announcing "new frames" in the log shifts from "0038" to "0044", with "0038" never being reused. Though, I don't think that means much -- possibly the game just lets the original rendering thread die and creates a new one (btw, the first thing both "0038" and "0044" ever log, respectively, is d3d9:d3d9_device_GetBackBuffer). I'd interpret this as being caused in the moment the launcher closes and the actual game gets started... at least this kind of makes sense.
When starting the application with its -dx9single flag, there is only one thread ("002f") doing all of the above work -- as expected.
Concerning +relay: I analyzed the log a bit and created an annotated except of it (see attachment). Thereby I concentrated on the last drawn frame and on the relay output of the threads with the aforementioned TIDs.
However, I did not yet take into account that the problem could also have its roots in a previous frame. This is because I hope that the reason for the freeze can already be derived from what I've got so far (in the attachment).
The most suspicious thing I see is a call to "user32.SendMessageW(...)" by TID 0044 apparently never returning... at least this could explain the many "KERNEL32.WaitForSingleObjectEx()" messages repeated over and over again by TID 002f, which might just be waiting for 0044. Btw, throughout the entire log (not just the excerpt), there is only one other call of TID 0044 to "user32.SendMessageW(...)" and that one's immediately returning (it can be seen at the end of the 3rd block in the attachment).
But I don't know if that's critical or how to go on from here. The reason for the freeze might also be something different in the log... or something I totally missed so far.
This is once more a request for help.
http://bugs.winehq.org/show_bug.cgi?id=31442
--- Comment #35 from voidcastr voidcastr@gmail.com 2012-10-07 09:01:47 CDT --- Created attachment 42008 --> http://bugs.winehq.org/attachment.cgi?id=42008 annotated relay log excerpt, as mentioned in comment #34
http://bugs.winehq.org/show_bug.cgi?id=31442
--- Comment #36 from Henri Verbeet hverbeet@gmail.com 2012-10-07 09:30:27 CDT --- (In reply to comment #34)
The most suspicious thing I see is a call to "user32.SendMessageW(...)" by TID 0044 apparently never returning... at least this could explain the many "KERNEL32.WaitForSingleObjectEx()" messages repeated over and over again by TID 002f, which might just be waiting for 0044. Btw, throughout the entire log (not just the excerpt), there is only one other call of TID 0044 to "user32.SendMessageW(...)" and that one's immediately returning (it can be seen at the end of the 3rd block in the attachment).
The 0x281 is WM_IME_SETCONTEXT. If that's really related, WINEDEBUG=+imm may be of interest, perhaps with some additional traces added to dlls/imm32/ to see where exactly it hangs. It's also possible that the window 0x80064 belongs to a different thread that isn't processing messages for some reason, e.g. because it's waiting for something itself.
http://bugs.winehq.org/show_bug.cgi?id=31442
--- Comment #37 from voidcastr voidcastr@gmail.com 2012-10-07 11:48:14 CDT --- (In reply to comment #36)
The 0x281 is WM_IME_SETCONTEXT. If that's really related, WINEDEBUG=+imm may be of interest, perhaps with some additional traces added to dlls/imm32/ to see where exactly it hangs. It's also possible that the window 0x80064 belongs to a different thread that isn't processing messages for some reason, e.g. because it's waiting for something itself.
After toying atound with +imm and some custom traces I can now confirm that HIMC WINAPI ImmAssociateContext(HWND hWnd, HIMC hIMC) in dlls/imm32/imm.c hangs after the call SendMessageW(data->IMC.hWnd, WM_IME_SETCONTEXT, TRUE, ISC_SHOWUIALL); at the very end of the function.
It is called by tid 0044, so I think we got the sticking point here... literally.
Out of curiosity I just commented that line and recompiled. Result: The application does not crash anymore when trying to chat or enter the name for a new character (i.e. focussing a chatbox). I can now play and chat without having to force the game to use single threaded rendering. Same result when commenting the data->IMC.hWnd = hWnd; between the two almost identical "if (IsWindow(data->IMC.hWnd))" blocks, so the 3rd param given to SendMessageW is not the problem either. Thus I suppose something's wrong with the semantics of "data->IMC.hWnd = hWnd;" or with the actual value of hWnd.
http://bugs.winehq.org/show_bug.cgi?id=31442
nob.dir.info@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |nob.dir.info@gmail.com
--- Comment #38 from nob.dir.info@gmail.com 2012-10-07 13:31:52 CDT --- Sounds like the imm32 bug of League of Legends (http://bugs.winehq.org/show_bug.cgi?id=30585 : try to replace SendMessageW with SendNotifyMessageW.
http://bugs.winehq.org/show_bug.cgi?id=31442
--- Comment #39 from voidcastr voidcastr@gmail.com 2012-10-07 13:44:27 CDT --- (In reply to comment #38)
Sounds like the imm32 bug of League of Legends (http://bugs.winehq.org/show_bug.cgi?id=30585 : try to replace SendMessageW with SendNotifyMessageW.
As expected this works when swapping the lower call to SendMessageW with SendNotifyMessageW, since the latter does not block (per definition from MSDN). The question remains if it is sensible to do so.
http://bugs.winehq.org/show_bug.cgi?id=31442
--- Comment #40 from nob.dir.info@gmail.com 2012-10-07 13:50:07 CDT --- I expect a thread problem...
http://bugs.winehq.org/show_bug.cgi?id=31442
--- Comment #41 from voidcastr voidcastr@gmail.com 2012-10-08 03:53:58 CDT ---
(In reply to comment #40)
I expect a thread problem...
Oh, that's quite for sure.
Well, apparently the lower SendMessageW is not handled properly under certain circumstances like the one being at hand here. Exchanging SendMessageW with SendNotifyMessageW would only obscure the actual problem that avoids the proper handling of the message. We should solve that instead.
I just investigated the message sending a little further:
As we know, SendMessageW(...) in dlls/user32/message.c is employed by the imm32 code in question. It calls send_message(struct send_message_info*, DWORD_PTR *, BOOL) which hangs at ret = send_inter_thread_message( info, &result ); in the "else" case at the end of the function.
This is because send_inter_thread_message(...) hangs at wait_message_reply( info->flags ); because wait_message_reply(...) hangs at wow_handlers.wait_message( 1, &server_queue, INFINITE, QS_SENDMESSAGE, 0 ); which refers to wait_message( DWORD, CONST HANDLE*, DWORD, DWORD, DWORD) in dlls/user32/winproc.c, which in turn hangs at ret = USER_Driver->pMsgWaitForMultipleObjectsEx( count, handles, timeout, mask, flags );.
From here, I kind of lose track of what's happening exactly. What I know for
sure is that X11DRV_MsgWaitForMultipleObjectsEx(DWORD, const HANDLE*, DWORD, DWORD, DWORD) in dlls/winex11.drv/event.c gets called over and over again, once every 5 seconds. The first time it returns calling WaitForMultipleObjectsEx under the "if (!data)" condition. Any subsequent call ends at the above "return WAIT_TIMEOUT;".
So, Henri, you already expected something related to WaitForMultipleObjects[Ex]... however this one was hard to find since there is no TRACE in the method. Seems like we're now deep into message handling and this has only little to nothing to do with wine's d3d implementation... How do we proceed from here?
http://bugs.winehq.org/show_bug.cgi?id=31442
--- Comment #42 from Henri Verbeet hverbeet@gmail.com 2012-10-08 05:29:41 CDT --- (In reply to comment #41)
From here, I kind of lose track of what's happening exactly. What I know for
What essentially happens is that we send the message to the server, and then wait for the reply. The server posts the message to the message queue of the thread that created the window in question. (I.e., info->dest_tid.) The destination thread is then supposed to retrieve the message from its message queue (typically this involves PeekMessage() or GetMessage()) and send a reply.
It would certainly be good to understand how all that works, but it's probably not where the problem is in this case. What you want to figure out is what thread the message gets sent to, and what that thread is doing at that point. I.e., why it's not processing the message.
http://bugs.winehq.org/show_bug.cgi?id=31442
--- Comment #43 from voidcastr voidcastr@gmail.com 2012-10-08 07:17:29 CDT --- I added some trace to message.c:send_message(...) TRACE_(mytrace)("dest_tid: %08x\n", info->dest_tid); TRACE_(mytrace)("this tid: %08x\n", GetCurrentThreadId()); TRACE_(mytrace)("message: %u\n", info->msg); right before the call of ret = send_inter_thread_message( info, &result );.
Result:
0044:trace:mytrace:send_message dest_tid: 0000002f 0044:trace:mytrace:send_message this tid: 00000044 0044:trace:mytrace:send_message message: 641
So tid 0044 is trying to send message code 641 to 002f... but in case I understand everything correctly this should cause a PeekMessageW or GetMessageW for 002f, as defined in dlls/user32/message.c. However, no such call occurs... at least custom traces added to the top of both functions never occur in the log. The same goes for put_message_in_queue(...).
I found out that 002f is in dlls/ntdll/sync.c NTDLL_wait_for_multiple_objects(...) at this time which it processes down to ret = wait_reply( &cookie ); in the first loop iteration. I added some traces araound that call because looking at the log, what happens there seems quite strange to me:
002f:trace:mytrace:NTDLL_wait_for_multiple_objects before wait_reply [call to wait_reply happens here] 002e:trace:mytrace:NTDLL_wait_for_multiple_objects after wait_reply
Note the shift from 002f to 002e while still processing NTDLL_wait_for_multiple_objects(...). How can this happen / is that intended?
http://bugs.winehq.org/show_bug.cgi?id=31442
--- Comment #44 from Henri Verbeet hverbeet@gmail.com 2012-10-08 08:03:00 CDT --- (In reply to comment #43)
So tid 0044 is trying to send message code 641 to 002f... but in case I understand everything correctly this should cause a PeekMessageW or GetMessageW for 002f, as defined in dlls/user32/message.c.
Well, not directly. 002f would call that as part of its normal event processing.
I found out that 002f is in dlls/ntdll/sync.c NTDLL_wait_for_multiple_objects(...)
So it's blocked waiting for something itself.
002f:trace:mytrace:NTDLL_wait_for_multiple_objects before wait_reply [call to wait_reply happens here] 002e:trace:mytrace:NTDLL_wait_for_multiple_objects after wait_reply
Note the shift from 002f to 002e while still processing NTDLL_wait_for_multiple_objects(...). How can this happen / is that intended?
I don't think that's really what happens, it's probably just 002e making a similar call before that now finishes.
We should probably move this to either private mail or IRC, bugzilla replies get sent to a lot of people.
http://bugs.winehq.org/show_bug.cgi?id=31442
--- Comment #45 from voidcastr voidcastr@gmail.com 2012-10-08 10:39:57 CDT --- (In reply to comment #44)
Alright, I also started worrying about this... expect the next message via mail. Tomorrow, most likely.
So, to anyone looking for a quick&dirty solution that involves recompiling wine: - edit dlls/imm32/imm.c: - head to "HIMC WINAPI ImmAssociateContext(HWND hWnd, HIMC hIMC)" - locate the line "SendMessageW(data->IMC.hWnd, WM_IME_SETCONTEXT, TRUE, ISC_SHOWUIALL);" at the end of the function - be careful, there are two similar lines... - replace "SendMessageW" with "SendNotifyMessageW" - recompile - play w/o -dx9single
I must emphasize that this is not a "real" fix -- I'd bet that it breaks something. But appears to be fine for GW2.
Btw, it does not fix the launcher. That seems to be another problem... so you need to enable auto-login.
http://bugs.winehq.org/show_bug.cgi?id=31442
--- Comment #46 from sworddragon2@aol.com 2012-10-08 14:16:38 CDT ---
We should probably move this to either private mail or IRC, bugzilla replies get sent to a lot of people.
I'm reading all the messages here and they don't disturb me. At least we are seeing that is something done here (instead of tickets which are months/years inactive).
http://bugs.winehq.org/show_bug.cgi?id=31442
Ramon Klass tier@schokokeks.org changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |tier@schokokeks.org
--- Comment #47 from Ramon Klass tier@schokokeks.org 2012-10-12 04:57:11 CDT --- this bug, or rather the launcher part of this bug, also seems to affect two-way authentication. I can't login anymore since typing anything in the authenticator field makes the launcher freeze
http://bugs.winehq.org/show_bug.cgi?id=31442
--- Comment #48 from voidcastr voidcastr@gmail.com 2012-10-12 05:07:49 CDT --- (In reply to comment #47)
this bug, or rather the launcher part of this bug, also seems to affect two-way authentication. I can't login anymore since typing anything in the authenticator field makes the launcher freeze
Gonna look into that as well in case we get the ingame part working.
Indeed there are multithreaded rendering issues for the launcher and for the actual game which seem to have distinct -- but I'd also bet similar -- causes. Though I really can't image why ANet are using multithreaded rendering for the launcher, but that appears to be the case.
Sadly I currently can't spare much time for debugging... however, that might change during the course of the next couple of days.
http://bugs.winehq.org/show_bug.cgi?id=31442
--- Comment #49 from KiXaM maxx_kixam@yahoo.fr 2012-11-25 12:46:28 CST --- Created attachment 42617 --> http://bugs.winehq.org/attachment.cgi?id=42617 Patch to be able to launch GW2 without -dx9single switch
This is only a workaround, and not sustainable at that.
https://bugs.winehq.org/show_bug.cgi?id=31442
--- Comment #50 from Austin English austinenglish@gmail.com --- Is this still an issue in current (1.7.35 or newer) wine? If so, please attach terminal output.
https://bugs.winehq.org/show_bug.cgi?id=31442
--- Comment #51 from Guillaume R guillaumeraffin@free.fr --- As of wine 1.7.38 this is no longer an issue.
https://bugs.winehq.org/show_bug.cgi?id=31442
super_man@post.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |super_man@post.com
--- Comment #52 from super_man@post.com --- (In reply to Guillaume R from comment #51)
As of wine 1.7.38 this is no longer an issue.
Can someone confirm?
https://bugs.winehq.org/show_bug.cgi?id=31442
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED
--- Comment #53 from Austin English austinenglish@gmail.com --- (In reply to Guillaume R from comment #51)
As of wine 1.7.38 this is no longer an issue.
Reported fixed.
https://bugs.winehq.org/show_bug.cgi?id=31442
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #54 from Alexandre Julliard julliard@winehq.org --- Closing bugs fixed in 1.7.54.
-
wine-bugs＠winehq.org