[Bug 47965] Head Over Heels crashes

[WineHQ Bugzilla]

https://bugs.winehq.org/show_bug.cgi?id=47965

Paul Gofman <gofmanp at gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |gofmanp at gmail.com

--- Comment #16 from Paul Gofman <gofmanp at 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.

-- 
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.