https://bugs.winehq.org/show_bug.cgi?id=42126
Bug ID: 42126 Summary: Super Bubsy crashes before intro screen Product: Wine Version: 2.0-rc3 Hardware: x86 OS: Mac OS X Status: NEW Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs@winehq.org Reporter: jeffz@jeffz.name
Created attachment 56665 --> https://bugs.winehq.org/attachment.cgi?id=56665 winedbg backtrace
MacOS 10.11.4 Intel Iris Pro graphics. wine-2.0-rc3-4-gc0b3043
Bubsy.exe either hangs:
fixme:win:EnumDisplayDevicesW ((null),0,0x32f6f8,0x00000000), stub! err:d3d:resource_init Failed to allocate system memory. fixme:d3d_shader:upload_palette P8 surface loaded without a palette.
or crashes without a backtrace:
fixme:win:EnumDisplayDevicesW ((null),0,0x32f6f8,0x00000000), stub! err:ddraw:device_parent_surface_created Failed to allocate surface memory. wine: Unhandled page fault on read access to 0x00000000 at address 0x423b4a (thread 0009), starting debugger...
Ran a regression test. Reverting the identified commit allows the game to run normally again.
1df961bd3d1a5d4d4badfe364ca51e9f6cc88fd3 is the first bad commit commit 1df961bd3d1a5d4d4badfe364ca51e9f6cc88fd3 Author: Ken Thomases ken@codeweavers.com Date: Fri Apr 29 01:59:30 2016 -0500
winemac: Implement the WGL_WINE_query_renderer extension.
Signed-off-by: Ken Thomases ken@codeweavers.com Signed-off-by: Alexandre Julliard julliard@winehq.org
:040000 040000 226385c889fe5acfcc2cbf51c42959f8c37cbb4d c1d1c8d8ae785ff9f24c35ba9ccbf17e2f7cd53b M dlls
https://bugs.winehq.org/show_bug.cgi?id=42126
Jeff Zaroyko jeffz@jeffz.name changed:
What |Removed |Added ---------------------------------------------------------------------------- Regression SHA1| |1df961bd3d1a5d4d4badfe364ca | |51e9f6cc88fd3 Keywords| |regression CC| |ken@codeweavers.com
https://bugs.winehq.org/show_bug.cgi?id=42126
--- Comment #1 from Ken Thomases ken@codeweavers.com --- That's weird. Can you please collect a +tid,+d3d,+wgl log?
Also, does setting the VideoMemorySize registry setting to something reasonable help?
https://bugs.winehq.org/show_bug.cgi?id=42126
winetest@luukku.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |winetest@luukku.com
--- Comment #2 from winetest@luukku.com --- This really shouldnt happen.
err:d3d:resource_init Failed to allocate system memory.
Does wine see your gpu correctly also the memory amount? Ths is basically what Ken asked.
https://bugs.winehq.org/show_bug.cgi?id=42126
--- Comment #3 from Jeff Zaroyko jeffz@jeffz.name --- (In reply to Ken Thomases from comment #1)
That's weird. Can you please collect a +tid,+d3d,+wgl log?
It seems to run endlessly (counting 2.9GB) unless I abort it. I'll attach head -n 100000 for starters. If it helps, the install is here: http://jeffz.name/super.zip (requires a dsetup.dll, run the setup.exe, then run c:\super bubsy\bubsy.exe, cancel on the CD prompt, navigate to the install directory, hit ok and it should run)
Also, does setting the VideoMemorySize registry setting to something reasonable help?
Yep. winetricks videomemorysize=512 for instance does prevent the crash.
https://bugs.winehq.org/show_bug.cgi?id=42126
--- Comment #4 from Jeff Zaroyko jeffz@jeffz.name --- Created attachment 56666 --> https://bugs.winehq.org/attachment.cgi?id=56666 head -n 100000 +seh,+tid,+wgl,+d3d
https://bugs.winehq.org/show_bug.cgi?id=42126
--- Comment #5 from Ken Thomases ken@codeweavers.com --- Thanks. It appears that you collected that log with the VideoMemorySize=512 setting in place, which avoids the crash. I need a log of the crashing case, without that registry setting.
The Mac driver WGL_WINE_query_renderer code detected 1536MB VRAM, which isn't too unreasonable. Out of curiosity, what does About This Mac show on the Displays tab?
https://bugs.winehq.org/show_bug.cgi?id=42126
--- Comment #6 from Jeff Zaroyko jeffz@jeffz.name --- (In reply to Ken Thomases from comment #5)
Thanks. It appears that you collected that log with the VideoMemorySize=512 setting in place, which avoids the crash. I need a log of the crashing case, without that registry setting.
The Mac driver WGL_WINE_query_renderer code detected 1536MB VRAM, which isn't too unreasonable. Out of curiosity, what does About This Mac show on the Displays tab?
Enabling the debug channels seems to stop the crash and instead just sits for minutes before where it normally crashes, so I wineserver -k, unless the crash is going to happen after several GB of output?
I've deleted the VideoMemorySize key and re-run: http://jeffz.name/+tid,+d3d,+wgl-Bubsy-try2.txt.bz2
The displays tab says Intel Iris Pro 1536 MB.
https://bugs.winehq.org/show_bug.cgi?id=42126
--- Comment #7 from Ken Thomases ken@codeweavers.com --- Thanks again. While I analyze the log, can you try one more thing for me? Revert the commit but then set VideoMemorySize=1536 and run without logging. Does the program still crash?
https://bugs.winehq.org/show_bug.cgi?id=42126
--- Comment #8 from Jeff Zaroyko jeffz@jeffz.name --- (In reply to Ken Thomases from comment #7)
Thanks again. While I analyze the log, can you try one more thing for me? Revert the commit but then set VideoMemorySize=1536 and run without logging. Does the program still crash?
Reverted the commit, set VideoMemorySize=1536 - It crashes the same way as the original report.
https://bugs.winehq.org/show_bug.cgi?id=42126
Ken Thomases ken@codeweavers.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords|regression | Regression SHA1|1df961bd3d1a5d4d4badfe364ca | |51e9f6cc88fd3 |
--- Comment #9 from Ken Thomases ken@codeweavers.com --- (In reply to Jeff Zaroyko from comment #8)
(In reply to Ken Thomases from comment #7)
Thanks again. While I analyze the log, can you try one more thing for me? Revert the commit but then set VideoMemorySize=1536 and run without logging. Does the program still crash?
Reverted the commit, set VideoMemorySize=1536 - It crashes the same way as the original report.
OK, thanks for checking that. I'm going to remove my commit and the regression tag. The only role my commit had was to properly determine the amount of VRAM. As you've determined, if the proper size had been set via the registry, the crash would have happened even before my commit.
Probably, this is a game bug and it just can't deal with the high amount of VRAM. The log shows it's in a loop of checking formats. I'm not sure why it doesn't crash when logging. That may indicate another game bug with an uninitialized variable such that Wine doing different things (like logging) leaves different leftover data in the game's variable and causes it to change behavior. It's also possible the logging just slowed it down and it would have eventually run out of memory and crashed given enough time (and disk space for the log).
It is possible that this is a bug in Wine (ddraw or wined3d), but I doubt it.
https://bugs.winehq.org/show_bug.cgi?id=42126
Matteo Bruni matteo.mystral@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |INVALID Status|NEW |RESOLVED
--- Comment #10 from Matteo Bruni matteo.mystral@gmail.com --- (In reply to Ken Thomases from comment #9)
Reverted the commit, set VideoMemorySize=1536 - It crashes the same way as the original report.
Probably, this is a game bug and it just can't deal with the high amount of VRAM.
Yeah, it seems to be one of those old ddraw games that allocate textures until the video memory is full... except that now that video memory is so large they run out of addressing space or break down in some other way.
I'm resolving this bug INVALID since it's most likely a game bug. I see you already left a note on Appdb about this so we should be all set (maybe move the comment out of the test report to make it more prominent? Your call though.)
https://bugs.winehq.org/show_bug.cgi?id=42126
Jeff Zaroyko jeffz@jeffz.name changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #11 from Jeff Zaroyko jeffz@jeffz.name --- Closing invalid.