https://bugs.winehq.org/show_bug.cgi?id=38394
Bug ID: 38394 Summary: Eador: Genesis crashes on exit (only in fullscreen mode) Product: Wine Version: 1.7.32 Hardware: x86 URL: http://files.games.1c.ru/eador/demo/eador_demo_setup.e xe OS: Linux Status: NEW Keywords: download, regression Severity: normal Priority: P2 Component: directx-d3d Assignee: wine-bugs@winehq.org Reporter: gyebro69@gmail.com CC: stefan@codeweavers.com Regression SHA1: f6dde7062413a1dfdd71acc92c5178ac66f3ade0 Distribution: ---
Created attachment 51247 --> https://bugs.winehq.org/attachment.cgi?id=51247 terminal output
Eador: Genesis crashes on exit when I'm running the game in Wine's traditional fullscreen mode and the game is set up to run in fullscreen. No crash occurs in virtual desktop mode. The crash happens quite frequently (9 out of 10 times) but sometimes the game exits properly.
Regression introduced by
f6dde7062413a1dfdd71acc92c5178ac66f3ade0 is the first bad commit commit f6dde7062413a1dfdd71acc92c5178ac66f3ade0 Author: Stefan Dösinger stefan@codeweavers.com Date: Tue Nov 18 21:26:57 2014 +0100
wined3d: Restore the display mode on focus change.
I tried the patch from bug #38064, but it didn't help.
Steps to reproduce the problem in the Russian demo: 1. installation should be straightforward despite of the Cyrillic text in the installer. 2. before running the game edit the file 'Eador.cfg' and change the option 'Windowed' to '0' 3. start the game with Eador.exe, press <Esc> to skip the intro. In the menu click the bottom-most button (выход), then click the button in the lower right corner. The game crashes on exit.
eador_demo_setup.exe sha1: 36bc92d257839c1232ecf55e873fcb44c04eb319
wine-1.7.40-99-gdc22283 Fedora 21 x86 / XOrg 1.16.3 / XFCE 4.10 / Nvidia binary drivers 340.76
https://bugs.winehq.org/show_bug.cgi?id=38394
Sebastian Lackner sebastian@fds-team.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |sebastian@fds-team.de
https://bugs.winehq.org/show_bug.cgi?id=38394
--- Comment #1 from Stefan Dösinger stefan@codeweavers.com --- I can reproduce this using KDE, but it is fairly rare. As far as I can see the game tries to call SetCooperativeLevel at the same time a focus loss happens, though it's not clear to me why exactly this crashes. I also think the focus loss itself is the problem, not the concurrency.
I tested this case with d3d9 when I wrote the focus handling patches. In d3d9 doing what the app seems to be doing results in a segfault on Windows.
https://bugs.winehq.org/show_bug.cgi?id=38394
--- Comment #2 from Stefan Dösinger stefan@codeweavers.com --- Actually, the problem isn't that tha game calls SetCooperativeLevel while the focus loss handling is in progress. The problem is destroys the ddraw object. Thus once the minimization is done and device_process_message wants to call device_parent->activate it reads freed memory and jumps to a random location (which happens to be 0x00000001).
Some more factoids: *) The same crash happens with Mate and FVWM.
*) This is not a race condition. The messages and SetCooperativeLevel call happen on the same thread. The SetCooperativeLevel call seems to happen in response to a message with id 0xc045. No idea what this is, I can't find it in the headers nor on Google. But it apparently is generated while we're minimizing the window. It is generated in more places
*) Inside a virtual desktop the WM_ACTIVATEAPP(wParam=0) message is never sent. When the game exits OK in KDE/FVWM/Mate the message also isn't generated.
*) The WM_ACTIVATEAPP message is apparently generated when the game destroys an unrelated window.
https://bugs.winehq.org/show_bug.cgi?id=38394
--- Comment #3 from Stefan Dösinger stefan@codeweavers.com --- Created attachment 51256 --> https://bugs.winehq.org/attachment.cgi?id=51256 Don't pump messages on mode changes
Can you give this patch a try? It fixes the crash for me, but it has some pretty bad problems.
Some details: message 0xc045 is a message internal to the application. It is in the message queue, sent by a different application thread, when the focus loss message is processed. During the focus loss handling wined3d calls ChangeDisplaySettingsEx, and winex11 eventually calls SendMessage(WM_X11DRV_RESIZE_DESKTOP). This sendmessage call (correctly) processes other messages in the message queue, so the application processes it's internal 0xc045 message while wined3d is in the focus loss handling code. The application destroys the ddraw object, and the wined3d code crashes.
Native ddraw also crashes if the ddraw object is destroyed during focus loss. However, ChangeDisplaySettings[Ex] is not supposed to pump messages according to my testing, though I still have to write a formal test for this.
Now the problem with the attached patch is that it delays mode changes by a few seconds when not using a virtual desktop. The cause for this is that nobody listens to messages on GetDesktopWindow() in this case, causing the SendMessageTimeoutW call to time out. When using SendMessage (or SendMessageTimeoutW without SMTO_BLOCK) the SendMessage call succeeds instantly, although I don't yet understand why, and WM_X11DRV_RESIZE_DESKTOP is never processed by X11DRV_WindowMessage.
https://bugs.winehq.org/show_bug.cgi?id=38394
--- Comment #4 from Stefan Dösinger stefan@codeweavers.com --- Actually, the WM_X11DRV_RESIZE_DESKTOP message is processed just fine without a virtual desktop. The problem was that if I don't launch explorer manually, Wine launches the 64 bit version, which I forgot to recompile when I added extra traces to winex11.drv...
So the patch should work fine, just don't forget to recompile your 64 bit winex11.drv if you have a 64 bit build...
I'm not sure if the WM_DISPLAYCHANGE change is right though. It is needed because otherwise the desktop thread will wait forever for the process that sent WM_X11DRV_RESIZE_DESKTOP, which in turn waits for the desktop thread, causing a deadlock that results in the timeout I observed.
https://bugs.winehq.org/show_bug.cgi?id=38394
--- Comment #5 from Béla Gyebrószki gyebro69@gmail.com --- The patch works here and the game quits properly.
https://bugs.winehq.org/show_bug.cgi?id=38394
--- Comment #6 from Stefan Dösinger stefan@codeweavers.com --- Unfortunately it is a bit more tricky though. The change means that the WM_DISPLAYCHANGE message isn't delivered before ChangeDisplaySettings returns. I thought this matches the behavior of Windows that I've once seen, but I cannot reproduce those old test results.
This entire message handling thing is a mess :-( .
https://bugs.winehq.org/show_bug.cgi?id=38394
Stefan Dösinger stefan@codeweavers.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #51256|0 |1 is obsolete| |
--- Comment #7 from Stefan Dösinger stefan@codeweavers.com --- Created attachment 51259 --> https://bugs.winehq.org/attachment.cgi?id=51259 Don't pump messages on mode changes (v2)
Here's another attempt. It calls the wndprocs of windows owned by the thread that calls ChangeDisplaySettings before ChangeDisplaySettings returns without processing queued messages. I haven't thought through all of the side effects yet though.
https://bugs.winehq.org/show_bug.cgi?id=38394
--- Comment #8 from Béla Gyebrószki gyebro69@gmail.com --- Does the patch have effect only when running apps in Wine's fullscreen mode or virtual desktop mode might be affected as well? (just in case I run into trouble with it).
https://bugs.winehq.org/show_bug.cgi?id=38394
--- Comment #9 from Stefan Dösinger stefan@codeweavers.com --- Virtual desktop mode is also affected by this patch.
https://bugs.winehq.org/show_bug.cgi?id=38394
Stefan Dösinger stefan@codeweavers.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #51259|0 |1 is obsolete| |
--- Comment #10 from Stefan Dösinger stefan@codeweavers.com --- Created attachment 51314 --> https://bugs.winehq.org/attachment.cgi?id=51314 winex11: Don't pump messages in ChangeDisplaySettings (v3)
Here's an updated version of my patch, addressing one of Alexandre's concerns. Can you test it? I had the game crash once when I tested it. I suspect it crashed because I forgot to run make, but I want to be sure it works for you as well before I send it.
https://bugs.winehq.org/show_bug.cgi?id=38394
--- Comment #11 from Béla Gyebrószki gyebro69@gmail.com --- (In reply to Stefan Dösinger from comment #10)
Created attachment 51314 [details] winex11: Don't pump messages in ChangeDisplaySettings (v3)
Here's an updated version of my patch, addressing one of Alexandre's concerns. Can you test it? I had the game crash once when I tested it. I suspect it crashed because I forgot to run make, but I want to be sure it works for you as well before I send it.
I tried the patch with multiple games beside Eador and it worked as expected.
https://bugs.winehq.org/show_bug.cgi?id=38394
super_man@post.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |super_man@post.com
--- Comment #12 from super_man@post.com --- (In reply to Béla Gyebrószki from comment #11)
(In reply to Stefan Dösinger from comment #10)
Created attachment 51314 [details] winex11: Don't pump messages in ChangeDisplaySettings (v3)
Here's an updated version of my patch, addressing one of Alexandre's concerns. Can you test it? I had the game crash once when I tested it. I suspect it crashed because I forgot to run make, but I want to be sure it works for you as well before I send it.
I tried the patch with multiple games beside Eador and it worked as expected.
The patch still applies against git so it's valid issue
1.7.51
https://bugs.winehq.org/show_bug.cgi?id=38394
--- Comment #13 from super_man@post.com --- Patch still applies cleanly
patching file dlls/user32/tests/sysparams.c Hunk #3 succeeded at 2931 (offset 24 lines). Hunk #4 succeeded at 3105 (offset 24 lines). patching file dlls/winex11.drv/desktop.c
against wine 1.8.rc3
https://bugs.winehq.org/show_bug.cgi?id=38394
--- Comment #14 from Bruno Jesus 00cpxxx@gmail.com --- Last attempt to send was in April 28, probably should just be resent after code freeze.
https://bugs.winehq.org/show_bug.cgi?id=38394
Stefan Dösinger stefandoesinger@gmx.at changed:
What |Removed |Added ---------------------------------------------------------------------------- CC|stefan@codeweavers.com |stefandoesinger@gmx.at
https://bugs.winehq.org/show_bug.cgi?id=38394
winetest@luukku.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |winetest@luukku.com
--- Comment #15 from winetest@luukku.com --- (In reply to Bruno Jesus from comment #14)
Last attempt to send was in April 28, probably should just be resent after code freeze.
The patch applies cleanly, just some offset changes.
patching file dlls/user32/tests/sysparams.c Hunk #3 succeeded at 2926 (offset 19 lines). Hunk #4 succeeded at 3100 (offset 19 lines). patching file dlls/winex11.drv/desktop.c Hunk #1 succeeded at 265 (offset -2 lines). Hunk #2 succeeded at 278 (offset -2 lines).
f6dde7062413a1dfdd71acc92c5178ac66f3ade0 commit seem to made several regressions.
https://bugs.winehq.org/buglist.cgi?quicksearch=f6dde7062413a1dfdd71acc92c51...
https://bugs.winehq.org/show_bug.cgi?id=38394
--- Comment #16 from winetest@luukku.com --- Still applies
patching file dlls/user32/tests/sysparams.c Hunk #3 succeeded at 2926 (offset 19 lines). Hunk #4 succeeded at 3100 (offset 19 lines). patching file dlls/winex11.drv/desktop.c Hunk #1 succeeded at 265 (offset -2 lines). Hunk #2 succeeded at 278 (offset -2 lines).
against wine 2.0.rc1.
The commit caused 3 known regressions bugs plus one that seems to be fixed with wine-stagign patch.
See also list should include bugs bug 38087 (staging patch), bug 37762 bug 38064.
https://bugs.winehq.org/show_bug.cgi?id=38394
joaopa jeremielapuree@yahoo.fr changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |jeremielapuree@yahoo.fr
--- Comment #17 from joaopa jeremielapuree@yahoo.fr --- I tried the demo. It looks like it is fixed for me. Can anyone confirm this bug is fixed in current wine(3.20)?
https://bugs.winehq.org/show_bug.cgi?id=38394
Béla Gyebrószki gyebro69@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |FIXED Status|NEW |RESOLVED
--- Comment #18 from Béla Gyebrószki gyebro69@gmail.com --- (In reply to joaopa from comment #17)
I tried the demo. It looks like it is fixed for me. Can anyone confirm this bug is fixed in current wine(3.20)?
Works for me too.
https://bugs.winehq.org/show_bug.cgi?id=38394
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #19 from Alexandre Julliard julliard@winehq.org --- Closing bugs fixed in 3.21.