SKY: Beneath a Steel Sky crashing on MacOS M1

[DanielNovak]

Running Beneath a Steel Sky on a M1 MacBook (M1 Pro, 32GB, latest Monterey 12.2) quits (force closes) the whole ScummVM.

How to reproduce:
1) Download Beneath a Steel sky, for example the CD VGA version from ​https://cdromance.com/scummvm/beneath-a-steel-sky-dos-cd-vga-scummvm-game/ (I tried other sources too, same result)
2) Use default ScummVM installation (I made a fresh install)
3) Launch app and wait during intro, it will crash after the first image of the old man. Or play the game and go from one screen to another (leave room).

I have played the same game, same settings and same source on a x86 macbook and it worked fine.
I looked into /Log/scummvm.log but it contains no relevant entries.

[criezy]

I can reproduce this issue but only with the native M1 version compiled with optimisation. Running a debug version, or a x86 version under Rosetta works properly.

This at least provides a workaround for the users as they can force running the ScummVM release versions under Rosetta:

• Select the ScummVM.app, and then press Command-I (or right-click / use the File menu and select Get Info). This will open an Info window with details about the app.
• In the Info window, look for a checkbox labeled, “Open using Rosetta”. Check the box.
• Start ScummVM and enjoy playing.

Details tests on a M1 mac:

• ScummVM 2.2.0 (Rosetta) does not crash
• ScummVM 2.5.1 (Native) crashes
• ScummVM 2.5.1 (Rosetta) does not crashes
• ScummVM 2.6.0 (Native) crashes
• ScummVM 2.6.0 (Rosetta) does not crashes
• master --enable-asan (Native): does not crash (no error reported by ASAN)
• master --enable-asan --enable-optimizations (Native): crashes (see report below)

ASAN report:

=================================================================
==77011==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x00012d8a0503 at pc 0x000100d93434 bp 0x00016f1b37d0 sp 0x00016f1b37c8
READ of size 1 at 0x00012d8a0503 thread T0
    #0 0x100d93430 in Sky::RncDecoder::unpackM1(void const*, void*, unsigned short) rnc_deco.cpp:249
    #1 0x100d6d364 in Sky::Disk::loadFile(unsigned short) disk.cpp:146
    #2 0x100d6ddb0 in Sky::Disk::refreshFilesList(unsigned int*) disk.cpp:287
    #3 0x100d673e4 in Sky::Control::parseSaveData(unsigned char*) control.cpp:1450
    #4 0x100d5f1cc in Sky::Control::restartGame() control.cpp:1549
    #5 0x100d9dddc in Sky::SkyEngine::go() sky.cpp:219
    #6 0x100da1134 in Sky::SkyEngine::run() sky.h:122
    #7 0x100d044d0 in scummvm_main main.cpp:619
    #8 0x100cf802c in main macosx-main.cpp:44
    #9 0x1894e542c in start+0x0 (libdyld.dylib:arm64e+0x1842c)

0x00012d8a0503 is located 765 bytes to the left of 70678-byte region [0x00012d8a0800,0x00012d8b1c16)
allocated by thread T0 here:
    #0 0x103dc0f54 in wrap_malloc+0x94 (libclang_rt.asan_osx_dynamic.dylib:arm64e+0x3cf54)
    #1 0x100d6d334 in Sky::Disk::loadFile(unsigned short) disk.cpp:127
    #2 0x100d6ddb0 in Sky::Disk::refreshFilesList(unsigned int*) disk.cpp:287
    #3 0x100d673e4 in Sky::Control::parseSaveData(unsigned char*) control.cpp:1450
    #4 0x100d5f1cc in Sky::Control::restartGame() control.cpp:1549
    #5 0x100d9dddc in Sky::SkyEngine::go() sky.cpp:219
    #6 0x100da1134 in Sky::SkyEngine::run() sky.h:122
    #7 0x100d044d0 in scummvm_main main.cpp:619
    #8 0x100cf802c in main macosx-main.cpp:44
    #9 0x1894e542c in start+0x0 (libdyld.dylib:arm64e+0x1842c)

I am worried this could be a compiler bug, in which case that could be complicated to fix.

[criezy]

I just tried the stable daily build for M1 (on ​https://buildbot.scummvm.org/#/dailybuilds) and that one seems to work properly as well. And as far as I know it is compiled with optimisations. So that could point toward a difference in the way it is compiled compared with official releases, and possibly an issue with the compiler (the compiler is not the same).

[lotharsm]

I am currently testing on my M1, using clang 13.1.6 and the current code from the master branch. For the game itself, I am using version "0.0372 cd" from our website and "v0.0368" linked above.

However, even with optimizations enabled, I couldn't trigger a crash neither in the intro nor when leaving the first room by escaping to the roof.

Am I missing something here? Surely the compiler is a bit older than on a current system (since I was lazy with updates which might come in handy right now), but it surely is newer than the version that was the current one 9 months ago...

Please note that I don't use the Xcode GUI and just use the configure and make commands.

[lotharsm]

I also had no luck with replicating it on branch-2-6 and v2.6.0 itself. Any idea what I'm doing - well - wrong?

[criezy]

dwa mentioned on discord that he cannot reproduce the crash either and he is using clang 14.0.0.

I just checked the version I am using and for some reason this is clang 13.0.0. I though I was already using the latest Xcode and clang available from Apple, but apparently this is not the case, so I will check that first.

I don't use the Xcode GUI and just use the configure and make commands

That's also what I do. It should not change anything though.

[lotharsm]

Okay, so should I wait with updating my machine in case we need to re-test something on clang 13.x? I'm not sure if a downgrade will be possible (I'm not that familiar with macOS yet).

[criezy]

I have now updated my toolchain and I have clang 14.0.0. With this version I can no longer reproduce the crash. So it looks like the issue was restricted to using clang 13.0.0.

I will keep this open for a little longer as I still want to check if we get any report with ubsan and tsan. But the good news is that the 2.6.1 release should be working properly.

[criezy]

I will close this now and chalk it off as a compiler bug.

I verified that with the updated toolchain the 2.6.1 version released today no longer crashes when starting the game.

I also tried to investigate further but neither ASAN or UBSAN reported anything relevant.