Opened 10 months ago
Closed 9 months ago
#14918 closed defect (fixed)
Orion Burger: Game breaking bug at Test 2 hamster wheel
Reported by: | afreickmann | Owned by: | afreickmann |
---|---|---|---|
Priority: | normal | Component: | Engine: M4 |
Version: | Keywords: | ||
Cc: | Game: | Orion Burger |
Description (last modified by )
As soon as Wilbur uses the hamster wheel in Test 2, either correctly with the machine or manually, ScummVM crashes. No workaround is known, making it a game-breaking issue.
Version: 2.9.0git1803 (windows-x86-64-master-de585f57)
Attachments (3)
Change History (15)
by , 10 months ago
by , 10 months ago
by , 10 months ago
Attachment: | burger.011 added |
---|
comment:1 by , 10 months ago
Description: | modified (diff) |
---|
comment:2 by , 10 months ago
comment:3 by , 10 months ago
Priority: | blocker → normal |
---|
comment:4 by , 10 months ago
This reads similar to the crash I'm getting with the demo of the game at the hamster wheel. The crash still persists for me on release builds (--enable-release) on Linux and MinGW (msys2 MinGW-w64)
(At one point I could also reproduce the door disappearing, but I could not reproduce it testing with today's build from master HEAD).
I have tested today after the recent commits for M4 (and for this issue) but the crash still occurs. On Linux it prints a "segmentation fault" or a "free(): double free detected in tcache 2 Aborted (core dumped)" message to the command line when crashing.
This matches with my notes in the previous bug ticket here: https://bugs.scummvm.org/ticket/14861#comment:4
The -Waggressive-loop-optimizations warning message during the build might be relevant:
engines/m4/graphics/krn_pal.cpp: In function ‘void M4::krn_fade_to_grey(M4::RGB8*, int32, int32)’: engines/m4/graphics/krn_pal.cpp:189:37: warning: iteration 32 invokes undefined behavior [-Waggressive-loop-optimizations] 189 | _GP(translation)[i] = (uint8)bestMatch; engines/m4/graphics/krn_pal.cpp:171:23: note: within this loop 171 | for (i = 0; i < 64; i++) { | ~~^~~~
comment:5 by , 10 months ago
Linking https://bugs.scummvm.org/ticket/14909 here, which also does not crash using a VS2022 build but does (or did) crash using the nightly builds.
comment:6 by , 10 months ago
Still hard crashing with build git1843, windows-x86-64-master-dbc231d6, Feb 5
FSDirectory::createReadStreamForMember('burger.has') -> 'D:\ScummVM\Games\Orion Burger\BURGER.HAS'
Opening hashed: burger.has
rgetting:612magnt -> from disk
612wheel
rtossing: 612_001a.RAW
FSDirectory::createReadStreamForMember('burger.has') -> 'D:\ScummVM\Games\Orion Burger\BURGER.HAS'
Opening hashed: burger.has
rgetting:602_004.RAW -> from disk
* Play wheel... 1
Run with push.
612mot03
FSDirectory::createReadStreamForMember('burger.has') -> 'D:\ScummVM\Games\Orion Burger\BURGER.HAS'
Opening hashed: burger.has
rgetting:612mot03 -> from disk
602door
comment:7 by , 10 months ago
And additional infos:
windows-x86-64-master-dbc231d6: hard crash
windows-x86-master-dbc231d6: as mentioned by dreammaster, no crash, but animation of door opening missing
win9x-master-dbc231d6: rock solid and animation of door as expected
comment:8 by , 10 months ago
Owner: | set to |
---|---|
Resolution: | → fixed |
Status: | new → closed |
Hot damn. Maybe it was the memory overrun identified by antoniou79, or something else I fixed, but on the latest daily build (2/15 74cfff3b), not only is there no crash, but the door opening animation worked flawlessly.
comment:9 by , 10 months ago
Unfortunately, this was still not fixed for me for the release builds (both Linux and Windows MinGW-w64).
But! I looked into this (more hours than I'd like to admit) and I think I've found the cause, and likely a solution, although maybe not very pretty. The cause seems to be that sometimes the engine will attempt to access freed up space and this does happen to be the case for the hamster wheel sequence.
I want to tweak the solution a bit more with the help of mem leak detection tools, and I'll open a PR for it (provided that it's still needed and not cover by another commit in the meantime). There also seems to be some issue with the magnet's animation (it's supposed to be vibrating while Wilbur is running, but in ScummVM it just quickly twitches at the start and then stays inanimate).
I only have the demo to test on, so hopefully this will apply for the complete game too.
comment:10 by , 10 months ago
Resolution: | fixed |
---|---|
Status: | closed → new |
No, unfortunately still an issue for
windows-x86-64-master-a2ed8657, git1990
But thank you for the analyzation, I really enjoy hearing of some of the issues, just not C++ developer.
comment:11 by , 10 months ago
THe memory leak seems to be really bad in the 64bit version at least, I still have several dead locks in the game, which are considered more arbitrary => memory leak at work. (e.g. several times after a talk with Astral/cutscene on the ship)
Considering the Windows (64bit) version is likely the most popular, this should be taken more serious, if i can help here, please give me tips on how to better log/identify these leaks.
comment:12 by , 9 months ago
Owner: | changed from | to
---|---|
Resolution: | → fixed |
Status: | new → closed |
Couldn't replicate error anymore with build windows-x86-64-master-66bc8190
Fixed the immediate crash problem. However, I notice there's still an issue with the door immediately disappearing rather than gradually opening up. However, annoyingly, this only happens in MinGW builds, and not in my Visual Studio build. So I'm leaving the bug open for now.