[Bug 51526] New: Game "The Longest 5 Minutes" crashing (Issue possibly in "/user32/winpos.c")
https://bugs.winehq.org/show_bug.cgi?id=51526
Bug ID: 51526 Summary: Game "The Longest 5 Minutes" crashing (Issue possibly in "/user32/winpos.c") Product: Wine Version: 6.12 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: user32 Assignee: wine-bugs@winehq.org Reporter: madbyte@tuta.io Distribution: ---
the Steam game "The Longest Five Minutes" crashes on start-up, apparently caused by not passing some variables (a window handle?). I used Wine GE 6.12 in this particular case.
WORKAROUND: Enabling virtual desktop in the prefix allows the game to launch.
Possible relevant bit (See full backtrace for more): "2 0x6edaf59c WINPOS_SysCommandSizeMove+0xeab(hwnd=<is not available>, wParam=<is not available>) [Z:\home\ubuntu\buildbot\runners\wine\wine-src\dlls\user32\winpos.c:3003] in user32 (0x0a24dd48)"
Link to Line 3003 in Wine GE 6.12: https://github.com/GloriousEggroll/wine/blob/cc2d9bd66c1207de3f8016cecd05d64...
Backtrace: https://gist.github.com/MadByteDE/fd9acf3deb29d885cb2fb2769402b1cf Proton Issue Page: https://github.com/ValveSoftware/Proton/issues/4849
https://bugs.winehq.org/show_bug.cgi?id=51526
Gijs Vermeulen gijsvrm@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- URL| |https://store.steampowered. | |com/app/504110/The_Longest_ | |Five_Minutes/ Summary|Game "The Longest 5 |The Longest Five Minutes |Minutes" crashing (Issue |crashes without virtual |possibly in |desktop |"/user32/winpos.c") |
--- Comment #1 from Gijs Vermeulen gijsvrm@gmail.com --- Custom wine versions and DXVK are not supported.
Could you try upstream wine, without DXVK and attach the terminal output?
https://bugs.winehq.org/show_bug.cgi?id=51526
--- Comment #2 from Lars Loe. madbyte@tuta.io --- sure. DXVK isn't the issue since it also happens with WINED3D. I tested vanilla wine, wine 6.13 staging as well as Proton Versions from 4.11 up to 6.3 - always the same issue.
Backtrace (Wine 6.13): https://gist.github.com/MadByteDE/e636c838978a2dd5f479cb23b2f71646
And here is the backtrace with virtual desktop enabled (playable state): https://gist.github.com/MadByteDE/22ffd81abd6679242650f67db37b4dbf
https://bugs.winehq.org/show_bug.cgi?id=51526
Lars Loe. madbyte@tuta.io changed:
What |Removed |Added ---------------------------------------------------------------------------- Version|6.12 |6.13
https://bugs.winehq.org/show_bug.cgi?id=51526
--- Comment #3 from Lars Loe madbyte@tuta.io --- More context: I noticed the game launches in maximized windowed mode no matter what is configured and after a moment switches to it's actual (configured) window size. The moment when this switch happens is the point where the game crashes without having virtual desktop enabled.
https://bugs.winehq.org/show_bug.cgi?id=51526
Gabriel Ivăncescu gabrielopcode@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |gabrielopcode@gmail.com
--- Comment #4 from Gabriel Ivăncescu gabrielopcode@gmail.com --- Since you referred this bug in 51672, can you please test with current wine git and see if anything changed?
https://bugs.winehq.org/show_bug.cgi?id=51526
Julian Rüger jr98@gmx.net changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |jr98@gmx.net
https://bugs.winehq.org/show_bug.cgi?id=51526
--- Comment #5 from Lars Loe madbyte@tuta.io --- I've tested the game with wine build from the latest git with [PATCH v9 2/2] user32: Don't save maximized pos of top-level wnds covering whole work rect enabled. Unfortunately there was no difference to my previous attempt(s).
https://bugs.winehq.org/show_bug.cgi?id=51526
--- Comment #6 from Gabriel Ivăncescu gabrielopcode@gmail.com --- Created attachment 70674 --> https://bugs.winehq.org/attachment.cgi?id=70674 Test hack
So the game creates a (hidden) window that's slightly larger than the screen, to offset the non-client area, but places it at (0,0) instead of something negative. In my case (1920x1080 screen), it creates a 1928x1107 window.
After it creates the window, it shows it. The problem is that the window manager gets involved at that point, and doesn't like such windows because they're off-screen. So it resizes it to 1920x1051 so it fits the work area (and for some reason, moves it to (0,2) as well, but that's probably not important), and then generates a ConfigureNotify event.
When wine's X11 driver sees this event, it attempts to sync the X11 window (that was resized/moved by the WM) with what the "windows side" sees it (which right now still believes the window to be in the old size). It does this by using a SetWindowPos if needed in X11DRV_ConfigureNotify (see winex11.drv/event.c), which among other things, ends up sending messages to the window.
For most apps this works fine, as they handle such alien SetWindowPos requests. There are exceptions though, and this game seems like one of them, but not the only one I know of. Note that theoretically, other apps could send SetWindowPos to any other app's window (at least if they have the required privilege), so it's not out of the ordinary what wine does here, it's just that the app doesn't expect it (but if you used e.g. AutoHotkey on Windows to send it at this specific time, it would probably crash as well).
Another bug that comes to mind is the old bug 15346, which suffers from similar issues due to that SetWindowPos and the WM moving/changing the window (in that case, WM refuses to move it off-screen), and seems unfixable without nasty hacks (the attached patch in it only band-aids the problem and breaks some older apps, as Alexandre mentioned on the mailing list, that expected the window to disappear if off-screen). In that bug, Winamp doesn't expect the SetWindowPos call either, it's not even processing a message loop at that point, and it keeps "track" of its movements manually, and that call breaks this assumption.
Strangely, for this particular game, it works fine if you put a Sleep for like 1000ms just before that call, which means it's something the game doesn't expect *at the time* it's generated, likely it uses something uninitialized yet. Sleeping for 100ms was not enough in my case though, but 1000ms is.
The attached hack (which obviously is *not* a solution) can be used to test if it works as well (you can try increase the Sleep if you want).
Other things that you can use that makes it work for me, and worth testing to replicate: Clear the "Allow the window manager to control the windows" in winecfg's Graphics tab. In this case the WM won't reconfigure the window if it doesn't like it. In Virtual Desktop it doesn't either, which is why it also works.
Ultimately I don't think this is fixable without some sort of nasty hack, unless someone comes up with a very clever idea, unfortunately. (and even then, getting Alexandre's approval for such fragile code will be very difficult)
https://bugs.winehq.org/show_bug.cgi?id=51526
Gabriel Ivăncescu gabrielopcode@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #70674|0 |1 is obsolete| |
--- Comment #7 from Gabriel Ivăncescu gabrielopcode@gmail.com --- Created attachment 70678 --> https://bugs.winehq.org/attachment.cgi?id=70678 Prevent the WM from resizing large windows
Actually, Zhiyi Zhang had this interesting idea to set the size hints for such large windows to disallow the WM from resizing them. This actually seems to work, here's an attached diff.
There's only one problem though: this probably means that the user won't be able to resize the window, though I haven't tested it, by e.g. dragging the border (MWM_FUNC_RESIZE is still set though). I don't think there's a way around it, and it's unlikely for someone to care about it if the window is so large to begin with. This is simply due to difference between Windows and X11 here. Windows doesn't touch large windows (that go beyond the work area), while WMs do without this hint.
I don't know if it's suitable for upstream but at least it's much nicer than other hacks. I'll try to write some tests first so, if it does get accepted, it won't regress.
https://bugs.winehq.org/show_bug.cgi?id=51526
--- Comment #8 from Lars Loe madbyte@tuta.io --- Thanks for digging into the issue!
I can confirm that clearing "Allow the window manager to control the windows" in winecfg helps and let the game launch normally.
Unfortunately the sleep code in winex11.drv/event.c doesn't seem to execute at all on my system (Manjaro, KDE Plasma, X11, AMDGPU). I also tried to change the sleep time to something ridiculous like 25000, but the system doesn't seem to wait when launching the game. I also tried to add a WARN to see if the text appears in the log but that didn't work either.
I also tried your latest patch to window.c and it works for me, the game launches without issues.
https://bugs.winehq.org/show_bug.cgi?id=51526
--- Comment #9 from Rafał Mużyło galtgendo@o2.pl --- I believe I've stumbled upon something similar.
An app work fine if fullscreen, but if you switch it to windowed, its window 'disappears'. By that I mean it seems to be moved partially off screen and unmapped - this is learned via xwininfo. If wmctrl is used to activate it, it shows up, but refuses to accept mouse input (not sure about the keyboard).
Problem also happens if you get it to start windowed.
https://bugs.winehq.org/show_bug.cgi?id=51526
--- Comment #10 from Gabriel Ivăncescu gabrielopcode@gmail.com --- (In reply to Rafał Mużyło from comment #9)
I believe I've stumbled upon something similar.
An app work fine if fullscreen, but if you switch it to windowed, its window 'disappears'. By that I mean it seems to be moved partially off screen and unmapped - this is learned via xwininfo. If wmctrl is used to activate it, it shows up, but refuses to accept mouse input (not sure about the keyboard).
Problem also happens if you get it to start windowed.
Are you sure it's only partially moved off screen and not completely? To be honest that really sounds like bug 15346. Having it unmapped when it's completely moved off screen is intended, but if it's only partial, it would be interesting to know why it happens.
What app is that? If it can't be tested, can you provide logs with +x11drv,+event,+cursor,+system,+win,+msg,+message ?
-
WineHQ Bugzilla