https://bugs.winehq.org/show_bug.cgi?id=39874
Bug ID: 39874 Summary: Alien Shooter crashes often with access violation Product: Wine Version: 1.8 Hardware: x86 OS: Linux Status: UNCONFIRMED Severity: major Priority: P2 Component: directx-d3d Assignee: wine-bugs@winehq.org Reporter: zakarjor@yahoo.com Distribution: ---
Alien shooter (1.2 Gog version) crashes often, usually when lots of actions occur (like massive number of aliens and explosions happening all at the same time.) The error log saved by the game inside Logs directory shows the following at the end:
!!!ERROR 09:28:10!!!SOUND: 0x6A Invalid nsfx !!!ERROR 09:28:43!!!TEXTURE: 0x8876086C Couldn't lock !!!ERROR EXCEPTION 0x41B57C!!!: Access violation write to 0x0
Looking at the wine source, it looks like LockRect() in d3d8/surface.c is returning D3DERR_INVALIDCALL after checking for invalid rect.
By patching the file to comment out the checking logic, the game seems to play flawlessly (currently played to level 10 without any crash.)
The checking logic seems to have been added in 2006: http://source.winehq.org/git/?p=wine.git;a=commit;h=77448f588b888ecc724c7ead...
I'm not sure if this is the right way to fix it, but at least it works, and I haven't seen any effect with other games I have. Looking at d3d9/surface.c, I can see that the checking logic doesn't exist in d3d9 LockRect(), and I've seen Internet examples of LockRect() passing invalid rectangles with impunity (like zero width rectangles).
https://bugs.winehq.org/show_bug.cgi?id=39874
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |regression CC| |austinenglish@gmail.com, | |stefandoesinger@gmx.at Regression SHA1| |77448f588b888ecc724c7ead9f2 | |8629f3f661d27 Severity|major |normal
https://bugs.winehq.org/show_bug.cgi?id=39874
Stefan Dösinger stefan@codeweavers.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |stefan@codeweavers.com
--- Comment #1 from Stefan Dösinger stefan@codeweavers.com --- d3d8 validates lock rectangles, as the tests in dlls/d3d8/tests/device.c shows. d3d9 afaik doesn't do that.
Does the game call LockRect through IDirect3DSurface8 directly, or does it call IDirect3DTexture8::LockRect? There may be different behavior between those two.
https://bugs.winehq.org/show_bug.cgi?id=39874
Stefan Dösinger stefandoesinger@gmx.at changed:
What |Removed |Added ---------------------------------------------------------------------------- CC|stefan@codeweavers.com |
https://bugs.winehq.org/show_bug.cgi?id=39874
--- Comment #2 from zakarjor@yahoo.com --- (In reply to Stefan Dösinger from comment #1)
d3d8 validates lock rectangles, as the tests in dlls/d3d8/tests/device.c shows. d3d9 afaik doesn't do that.
Does the game call LockRect through IDirect3DSurface8 directly, or does it call IDirect3DTexture8::LockRect? There may be different behavior between those two.
The log seems to indicate IDirect3DTexture8::LockRect().
Maybe zero-width rectangle is not such an invalid rectangle, as long as it's non-negative widths and heights? I don't have Windows to verify the original behavior. I'm also not sure whether Windows have special-case of compatibility for this game. At least I found out that level 10 was the last level, so I was able to play thru the whole game.
https://bugs.winehq.org/show_bug.cgi?id=39874
--- Comment #3 from Stefan Dösinger stefandoesinger@gmx.at --- Created attachment 53436 --> https://bugs.winehq.org/attachment.cgi?id=53436 d3d8: Don't validate 2D texture lock coordinates.
Can you give this patch a try? Apparently d3d8 validates the rectangle when locking surfaces and cube textures, but not for 2D textures. The entry point (texture::lockrect vs surface::lockrect) doesn't matter.
I have tests that back up the change, but I want to take a look at finding a proper fix for the todo_wine in an existing test that I am adding.
https://bugs.winehq.org/show_bug.cgi?id=39874
--- Comment #4 from Stefan Dösinger stefandoesinger@gmx.at --- Should be fixed by a2d3b3a5a58cdacb8bf09cb927a3421d9e3cc32a, please retest.
https://bugs.winehq.org/show_bug.cgi?id=39874
Stefan Dösinger stefandoesinger@gmx.at changed:
What |Removed |Added ---------------------------------------------------------------------------- Fixed by SHA1| |a2d3b3a5a58cdacb8bf09cb927a | |3421d9e3cc32a Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED
--- Comment #5 from Stefan Dösinger stefandoesinger@gmx.at --- Forgot to update the status in my last comment...
https://bugs.winehq.org/show_bug.cgi?id=39874
--- Comment #6 from zakarjor@yahoo.com --- I tested the patch and it does seem to work. I was able to progress up to level 4 (it usually crashes within level 1 or 2).
https://bugs.winehq.org/show_bug.cgi?id=39874
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #7 from Alexandre Julliard julliard@winehq.org --- Closing bugs fixed in 1.9.2.
https://bugs.winehq.org/show_bug.cgi?id=39874
Michael Stefaniuc mstefani@redhat.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |mstefani@redhat.com Target Milestone|--- |1.8.x
https://bugs.winehq.org/show_bug.cgi?id=39874
Michael Stefaniuc mstefani@redhat.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Target Milestone|1.8.x |---
--- Comment #8 from Michael Stefaniuc mstefani@redhat.com --- Removing 1.8.x milestone from bugs included in 1.8.5.
-
wine-bugs＠winehq.org