[Bug 38627] New: Holy Avatar vs. Maidens of the Dead hangs on exit
https://bugs.winehq.org/show_bug.cgi?id=38627 Bug ID: 38627 Summary: Holy Avatar vs. Maidens of the Dead hangs on exit Product: Wine Version: 1.5.31 Hardware: x86 OS: Linux Status: NEW Keywords: regression Severity: normal Priority: P2 Component: kernel32 Assignee: wine-bugs(a)winehq.org Reporter: gyebro69(a)gmail.com CC: dmitry(a)baikal.ru Regression SHA1: bfcdf6df8eea1230fb0e1835a809e49e5971e5d2 Distribution: --- Created attachment 51534 --> https://bugs.winehq.org/attachment.cgi?id=51534 terminal output I let the Desura client install the game to avoid bug #38614. The game starts properly without any winetricks, but it hangs on exit. After selecting quit from the menu, the screen is frozen and the game executable constantly uses 100% CPU and it needs to be killed. The problem is present since bfcdf6df8eea1230fb0e1835a809e49e5971e5d2 is the first bad commit commit bfcdf6df8eea1230fb0e1835a809e49e5971e5d2 Author: Dmitry Timoshkov <dmitry(a)baikal.ru> Date: Mon May 13 16:46:37 2013 +0900 kernel32: Terminate threads before unloading DLLs on process exit. No demo version exists. Let me know if you need debug logs or further testing. Tested in wine-1.7.43-123-g90ed96a -- 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.
https://bugs.winehq.org/show_bug.cgi?id=38627 --- Comment #1 from Dmitry Timoshkov <dmitry(a)baikal.ru> --- Does installing native msvcrt/msvcp help? If not, please generate +relay,+seh,+tid log (without wine startup by generating log from a separate terminal and in append '>>' mode). -- 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.
https://bugs.winehq.org/show_bug.cgi?id=38627 --- Comment #2 from Béla Gyebrószki <gyebro69(a)gmail.com> --- Created attachment 51535 --> https://bugs.winehq.org/attachment.cgi?id=51535 +relay,+seh,+tid partial log (uncompressed 98 MB) (In reply to Dmitry Timoshkov from comment #1)
Does installing native msvcrt/msvcp help? If not, please generate +relay,+seh,+tid log (without wine startup by generating log from a separate terminal and in append '>>' mode).
The game uses msvcp90,msvcr90 but installing native ones doesn't help. Native msvcrt.dll doesn't help either. The full +relay log is nearly 3 GB, the attached file contains the last 1.5 million lines of that log. Is that of any help to you? -- 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.
https://bugs.winehq.org/show_bug.cgi?id=38627 --- Comment #3 from Béla Gyebrószki <gyebro69(a)gmail.com> --- The vast majority of the full +relay log (2.9 GB) consists of the same msvcp90/msvcr90 calls so I could squeeze it into a 30 MB .7z archive: https://drive.google.com/open?id=0B-tTbLKBl-tONjJ5RWo1ZmlCYzQ What if I create a +relay with native msvcp90/msvcr90 installed? The problem is present with native too, and that would reduce the log size to a humble 200 MB? Or would that make debugging more difficult? -- 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.
https://bugs.winehq.org/show_bug.cgi?id=38627 --- Comment #4 from Dmitry Timoshkov <dmitry(a)baikal.ru> --- (In reply to Béla Gyebrószki from comment #2)
Created attachment 51535 [details] +relay,+seh,+tid partial log (uncompressed 98 MB)
Thanks. There is an access violation exception in Vision90.dll when it handles PROCESS_DETACH event. An exception occurs right after the following calls: wined3d.wined3d_buffer_decref()=0 wined3d.wined3d_mutex_unlock()=0 These calls should go from inside of Wine ddraw*/d3d* dlls, but there is no appropriate relay calls for them in the log, so it's impossible to say what is going on exactly. I'd guess that in order to investigate further one needs to see what's wrong with ddraw*/d3d*, as a wild guess may be one of these dlls invokes a callback on destruction which application doesn't expect at this point, but that's a pure speculation. (In reply to Béla Gyebrószki from comment #3)
The vast majority of the full +relay log (2.9 GB) consists of the same msvcp90/msvcr90 calls so I could squeeze it into a 30 MB .7z archive: https://drive.google.com/open?id=0B-tTbLKBl-tONjJ5RWo1ZmlCYzQ
What if I create a +relay with native msvcp90/msvcr90 installed? The problem is present with native too, and that would reduce the log size to a humble 200 MB? Or would that make debugging more difficult?
It would be more interesting to force ddraw*/d3d* calls appear in the log, but I can't off the top of my head suggest how to do that, probably playing with RelayExclude/RelayInclude keys in the registry would make the trick. Although reducing the log using native msvc* dlls should still keep interesting parts in the log. -- 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.
https://bugs.winehq.org/show_bug.cgi?id=38627 --- Comment #5 from Dmitry Timoshkov <dmitry(a)baikal.ru> --- Another thing to investigate is a hang before Ctrl+C exception: probably vBase90.dll: thread_proc() { for(;;) WaitForSingleObject(hevent, INFINITE); } hevent = CreateEvent(0,0,0,0); CreateThread(thread_proc); vBase90.dll,PROCESS_DETACH: SetEvent(hevent); <= probably hangs here, there is no return before Ctrl+C -- 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.
https://bugs.winehq.org/show_bug.cgi?id=38627 --- Comment #6 from Béla Gyebrószki <gyebro69(a)gmail.com> --- Created attachment 51544 --> https://bugs.winehq.org/attachment.cgi?id=51544 winedbg bt all Not sure how I could help you resolve this bug.. I attached winedbg to the already hung process (only 1 thread was running) and issued 'bt all'. Looks like it hangs in vBase90.dll indeed. -- 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.
https://bugs.winehq.org/show_bug.cgi?id=38627 --- Comment #7 from Dmitry Timoshkov <dmitry(a)baikal.ru> --- Is it possible to generate a log without the hang? (with either the offending patch reverted in current git or before the commit point). -- 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.
https://bugs.winehq.org/show_bug.cgi?id=38627 --- Comment #8 from Béla Gyebrószki <gyebro69(a)gmail.com> --- Created attachment 51548 --> https://bugs.winehq.org/attachment.cgi?id=51548 +relay,+seh,+tid (wine-1.5.30-128-g7ad43e4) The last 1 million lines of the +relay log, created in wine-1.5.30-128-g7ad43e4 (one commit before the regression). The game exits cleanly. -- 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.
https://bugs.winehq.org/show_bug.cgi?id=38627 --- Comment #9 from Dmitry Timoshkov <dmitry(a)baikal.ru> --- (In reply to Dmitry Timoshkov from comment #5)
Another thing to investigate is a hang before Ctrl+C exception:
probably vBase90.dll: thread_proc() { for(;;) WaitForSingleObject(hevent, INFINITE); }
hevent = CreateEvent(0,0,0,0); CreateThread(thread_proc);
vBase90.dll,PROCESS_DETACH: SetEvent(hevent); <= probably hangs here, there is no return before Ctrl+C
After looking at the vBase90.dll disassembly what application actually does is slightly different: vBase90.dll: int var_to_test; thread_proc() { for(;;) WaitForSingleObject(hevent, INFINITE); var_to_test = 1; } var_to_test = 0; hevent = CreateEvent(0,0,0,0); CreateThread(thread_proc); ... ExitProcess(0); ... vBase90.dll,PROCESS_DETACH: SetEvent(hevent); while (var_to_test != 1) /* wait*/; <= hangs here The applications expects that variable var_to_test is set by the thread proc after the event is signalled, but all the threads are already dead at the point of PROCESS_DETACH event, so the app hangs forever waiting for the variable. So far I failed to reproduce this application's expectation with a test under Windows7, the thread gets killed before the PROCESS_DETACH event. My guess was that the event could get an abandoned state during thread termination by ExitProcess, so that WaitForSingleObejct() would return and allow setting the variable, but so far I couldn't confirm that theory. -- 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.
https://bugs.winehq.org/show_bug.cgi?id=38627 --- Comment #10 from Dmitry Timoshkov <dmitry(a)baikal.ru> --- (In reply to Dmitry Timoshkov from comment #9)
vBase90.dll: int var_to_test; thread_proc() { for(;;) WaitForSingleObject(hevent, INFINITE); var_to_test = 1; }
Of course the line for(;;) WaitForSingleObject(hevent, INFINITE); should be WaitForSingleObject(hevent, INFINITE); -- 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.
https://bugs.winehq.org/show_bug.cgi?id=38627 --- Comment #11 from Dmitry Timoshkov <dmitry(a)baikal.ru> --- (In reply to Dmitry Timoshkov from comment #9)
The applications expects that variable var_to_test is set by the thread proc after the event is signalled, but all the threads are already dead at the point of PROCESS_DETACH event, so the app hangs forever waiting for the variable.
So far I failed to reproduce this application's expectation with a test under Windows7, the thread gets killed before the PROCESS_DETACH event. My guess was that the event could get an abandoned state during thread termination by ExitProcess, so that WaitForSingleObejct() would return and allow setting the variable, but so far I couldn't confirm that theory.
A probable explanation could be that variable var_to_test might be set from some other place besides the thread_proc, and it's another bug revealed by the thread termination on process exit. -- 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.
https://bugs.winehq.org/show_bug.cgi?id=38627 --- Comment #12 from Dmitry Timoshkov <dmitry(a)baikal.ru> --- Béla, could you please test the game under Windows? Does it exit cleanly there? -- 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.
https://bugs.winehq.org/show_bug.cgi?id=38627 --- Comment #13 from Béla Gyebrószki <gyebro69(a)gmail.com> --- (In reply to Dmitry Timoshkov from comment #12)
Béla, could you please test the game under Windows? Does it exit cleanly there?
I set up a Virtualbox VM running Windows XP SP3 in it because I don't have Windows installed, but the game failed to start even when 3D was enabled in the VM. The game complained about unsupported render target format and exited. -- 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.
https://bugs.winehq.org/show_bug.cgi?id=38627 Anastasius Focht <focht(a)gmx.net> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |focht(a)gmx.net -- 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.
https://bugs.winehq.org/show_bug.cgi?id=38627 --- Comment #14 from Béla Gyebrószki <gyebro69(a)gmail.com> --- Still present in 1.9.22. -- 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.
https://bugs.winehq.org/show_bug.cgi?id=38627 joaopa <jeremielapuree(a)yahoo.fr> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jeremielapuree(a)yahoo.fr --- Comment #15 from joaopa <jeremielapuree(a)yahoo.fr> --- Is still a bug in current wine(3.20)? -- 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.
https://bugs.winehq.org/show_bug.cgi?id=38627 Béla Gyebrószki <gyebro69(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |INVALID Keywords|regression | Component|kernel32 |-unknown Status|NEW |RESOLVED Regression SHA1|bfcdf6df8eea1230fb0e1835a80 | |9e49e5971e5d2 | --- Comment #16 from Béla Gyebrószki <gyebro69(a)gmail.com> --- This bug was reported against the Desura version of the game. The title screen shows v.0.0.8.1 builddate Sep 7 2012 as the game version. Desura digital distribution platform went offline years ago and apparently they've never released a patch for this game. Now I tried the Steam version (v1.0.0.0 builddate Feb 19 2014) and it doesn't have the reported problem, the game quits properly. Marking invalid (possibly a bug in the early version of the game). -- 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.
https://bugs.winehq.org/show_bug.cgi?id=38627 Béla Gyebrószki <gyebro69(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED --- Comment #17 from Béla Gyebrószki <gyebro69(a)gmail.com> --- Closing invalid bug. -- 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.
participants (1)
-
wine-bugs＠winehq.org