Orion Burger: Game breaking bug at Test 2 hamster wheel

[afreickmann]

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)

[dreammaster]

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.

[antoniou79]

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++) {
      |                     ~~^~~~

[codengine]

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.

[afreickmann]

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

[afreickmann]

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

[dreammaster]

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.

[antoniou79]

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.

[afreickmann]

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.

[afreickmann]

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.

[afreickmann]

Couldn't replicate error anymore with build windows-x86-64-master-66bc8190