https://bugs.winehq.org/show_bug.cgi?id=47965
Paul Gofman gofmanp@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |gofmanp@gmail.com
--- Comment #16 from Paul Gofman gofmanp@gmail.com --- Created attachment 66242 --> https://bugs.winehq.org/attachment.cgi?id=66242 poc hack
I've tested the game and could reliably reproduce the problem (under Gnome WM which might be important).
First of all, it doesn't look like a regression to me, at least relatively recent one. The problem is reproducible with stable 4.0 Wine version.
The crash is triggered by the game window proc receiving WM_PAINT with empty clip rectangle, that is, when rcPaint in PAINTSTRUCT returned from BeginPaint() contains zero rectangle. The game maps a ddraw surface, and if rcPaint is zero it gets confused by that and accesses the mapped surface past end the surface size (640x480).
The game does not crash if Wine is run with 'Emulate Windows desktop' set in winecfg. Another workaround is to disable 'Allow the window manager to control the windows'. It also doesn't crash if previously configured to work in fullscreen mode. Also when I use LXDE instead of Gnome I can start the game without virtual desktop most of the time, while sometimes it still crashes.
I have identified two cases when game receives a "bad" paint request when run without workaround mentioned above:
1. WM expose even processing in winex11.drv/event.c:X11DRV_Expose(), when event x y are 0 and event width, height are 1.
2. MoveWindow() called from application itself to move the window to the center of the screen. What probably makes the difference with LXDE is that I get the game window already centered at start (unlike that with Gnome when I get the window in the upper left corner first and it is always moved).
I am attaching the patch which hacks around these two cases, with this patch applied I could not reproduce the crashes.
Summarizing all this, I am not sure these results point to exact root cause of the issue, though probably explain what it is about. It doesn't look like a regression introduced during the last development cycle, the issue is probably much older.
Maybe there is a room for further digging on what is the difference in message sequence / details in respect to MoveWindow. It looks though that the source of the difference comes from WM interference.