https://bugs.winehq.org/show_bug.cgi?id=54701
Bug ID: 54701 Summary: Regression in Ultimate Race Pro Product: Wine-staging Version: 8.3 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs@winehq.org Reporter: adec2011.ac@gmail.com CC: leslie_alistair@hotmail.com, z.figura12@gmail.com Distribution: ---
Used to work but now i get this when running in 8.3
wine: Unhandled page fault on write access to FF000004 at address 7BC276F3 (thread 0148), starting debugger...
https://bugs.winehq.org/show_bug.cgi?id=54701
Gijs Vermeulen gijsvrm@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Ever confirmed|0 |1 Keywords| |regression Summary|Regression in Ultimate Race |Ultimate Race Pro crashes |Pro |on start Status|UNCONFIRMED |NEEDINFO
--- Comment #1 from Gijs Vermeulen gijsvrm@gmail.com --- Does it work with upstream (non-staging) wine or does it also crash?
Please attach (not paste) the full terminal output, see: https://wiki.winehq.org/FAQ#How_can_I_get_a_debugging_log_.28a.k.a._terminal...
Is there a free and legal download to reproduce this with?
https://bugs.winehq.org/show_bug.cgi?id=54701
--- Comment #2 from AdeC adec2011.ac@gmail.com --- THe only output from the terminal is this
wine: Unhandled page fault on write access to FF000004 at address 7BC276F3 (thread 0130), starting debugger...
The only place i can see a demo is at https://archive.org/details/DEMOUR
https://bugs.winehq.org/show_bug.cgi?id=54701
Gijs Vermeulen gijsvrm@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Component|-unknown |d3d Summary|Ultimate Race Pro crashes |Ultimate Race Pro crashes |on start |after intro movies Version|8.3 |8.4 Status|NEEDINFO |NEW Keywords| |download URL| |https://archive.org/downloa | |d/DEMOUR/DEMOUR.EXE Product|Wine-staging |Wine
--- Comment #3 from Gijs Vermeulen gijsvrm@gmail.com --- I can confirm a crash with the demo, attaching a +d3d log. Since this is an older game, I used a 32bit prefix set to Win98.
Adding stable download.
$ sha1sum DEMOUR.EXE ff82526342304856d573e07cfe419a603a6f07d7 DEMOUR.EXE
$ du -sh DEMOUR.EXE 25M DEMOUR.EXE
https://bugs.winehq.org/show_bug.cgi?id=54701
--- Comment #4 from Gijs Vermeulen gijsvrm@gmail.com --- Created attachment 74218 --> https://bugs.winehq.org/attachment.cgi?id=74218 +d3d (compressed, 97MB uncompressed)
https://bugs.winehq.org/show_bug.cgi?id=54701
Gijs Vermeulen gijsvrm@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Version|8.4 |7.15
--- Comment #5 from Gijs Vermeulen gijsvrm@gmail.com --- It works with wine-7.14 and start crashing with wine-7.15. Running a bisect now.
https://bugs.winehq.org/show_bug.cgi?id=54701
Gijs Vermeulen gijsvrm@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC|leslie_alistair@hotmail.com |stefan@codeweavers.com |, z.figura12@gmail.com |
--- Comment #6 from Gijs Vermeulen gijsvrm@gmail.com --- Bisect revealed:
8bddb9808eb5b79bc03a06c20a9b23fc34537d5e is the first bad commit commit 8bddb9808eb5b79bc03a06c20a9b23fc34537d5e Author: Stefan Dösinger stefan@codeweavers.com Date: Mon Jul 25 10:09:29 2022 +0300
ddraw: Don't account video memory for sysmem surfaces' draw textures.
Star Trek Starfleet Academy does not like it when available video memory goes down after creating a system memory resource. It destroys all its textures and recreates them, and in some sitations forgets to recreate one or another texture, resulting in rendering bugs.
I suspect the game is trying to detect focus loss by monitoring for unexpected video memory changes.
dlls/ddraw/surface.c | 1 + 1 file changed, 1 insertion(+)
https://bugs.winehq.org/show_bug.cgi?id=54701
Gijs Vermeulen gijsvrm@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Regression SHA1| |8bddb9808eb5b79bc03a06c20a9 | |b23fc34537d5e
https://bugs.winehq.org/show_bug.cgi?id=54701
--- Comment #7 from Stefan Dösinger stefan@codeweavers.com --- I can reproduce this crash and confirm that reverting the patch makes it go away.
The patch might have just triggered a pre-existing problem though. There seems to be a heap corruption.
https://bugs.winehq.org/show_bug.cgi?id=54701
--- Comment #8 from Stefan Dösinger stefan@codeweavers.com --- The game occasionally crashes on Windows in the same way.
https://bugs.winehq.org/show_bug.cgi?id=54701
--- Comment #9 from Stefan Dösinger stefan@codeweavers.com --- The problem is that WINED3DUSAGE_PRIVATE resources don't get unloaded on wined3d_device_reset() calls because they are not added to the resource list. ddraw can't piggy-pack on this flag to prevent per-resource video memory accounting.
After recreating the context, the draw texture still has a GL texture id assigned. wined3d will try to download data from this texture. With core contexts, glBindTexture rejects the bad texture name and glGetTexImage will return data from a different, larger texture, corrupting the heap.
I think I'll do away with WINED3D_VIDMEM_ACCOUNTING and replace it with a per-resource flag.
I contemplated unloading the draw texture in the reset() callback, but wined3d does not export a per-resource unload function and I don't think it should.
https://bugs.winehq.org/show_bug.cgi?id=54701
Gijs Vermeulen gijsvrm@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Fixed by SHA1| |723cd0a4ae76ec45320290893c7 | |af7f90b668556 Status|NEW |RESOLVED Resolution|--- |FIXED
--- Comment #10 from Gijs Vermeulen gijsvrm@gmail.com --- This is fixed by: https://gitlab.winehq.org/wine/wine/-/commit/723cd0a4ae76ec45320290893c7af7f...
Thanks for the quick fix Stefan!
https://bugs.winehq.org/show_bug.cgi?id=54701
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #11 from Alexandre Julliard julliard@winehq.org --- Closing bugs fixed in 8.5.