SCUMM: mac_m68k.cpp crash with enable_gs=true in atlantis-mac

[boredzo]

scummvm -v:
ScummVM 2.7.1pre15-g9f7feabc579 (Feb 21 2023 09:02:24)
Features compiled in: Vorbis FLAC MP3 TiMidity RGB zLib MPEG2 FluidSynth Theora AAC A/52 FreeType2 FriBiDi JPEG PNG GIF taskbar TTS cloud (servers, local) TinyGL OpenGL (with shaders) OpenGL desktop only RetroWave

STR:

1. Launch ScummVM.
2. Start “Indiana Jones and the Fate of Atlantis”.
3. At any point during gameplay (including the gameplay parts of the credits sequence, and when gameplay begins proper when you get to New York City), press F5.

Language: English.

Game variant: Macintosh CD.

OS: macOS Monterey 12.3.1.

Save game: No can do. I'd have to be able to F5 to do that.

Previous versions: 2.6 crashes upon trying to start the game, so I can't test whether it crashes upon trying to F5. 2.7 beta is necessary to even get to gameplay.

[dwatteau]

Thank you for reporting this.

There were several Macintosh releases of Indy4, do you know if yours is a talkie release? I can't reproduce the crash with the talkie Macintosh release I own here.

Do you have the "Enable the original GUI and Menu" setting enabled? Does changing it make a difference?

Also, can you confirm that your files aren't corrupted in some way? Because we're not aware of any crash in 2.6 either for this release. Here's some output from mine:

$ md5 ATLANTIS.00*
MD5 (ATLANTIS.000) = 1a6e5ae2777a6a33f06ffc0226210934
MD5 (ATLANTIS.001) = 03e3e717d2bf2ee42fff796db50cb69f

$ ls -l ATLANTIS.00*
  11885 Jan  3  1994 ATLANTIS.000
8782535 Jan  3  1994 ATLANTIS.001

Please also make sure that you have properly copied the 'iMuse Setups' file from the original CD. If you're storing the game on an HFS/HFS+/APFS disk, you can copy the file as is, otherwise have a look at <​https://docs.scummvm.org/en/v2.7.0/use_scummvm/mac_game_files.html>.

By the way, for other SCUMM hackers, here's the relevant line from the IPS file above:

Assertion failed: (false), function send, file mac_m68k.cpp, line 116.

[boredzo]

There were several Macintosh releases of Indy4, do you know if yours is a talkie release? I can't reproduce the crash with the talkie Macintosh release I own here.

It's a talkie.

Do you have the "Enable the original GUI and Menu" setting enabled?

Yes. (By default, apparently. I didn't check it.)

Does changing it make a difference?

Nope, still crashes. (I'll attach the new crash log but it looks the same.)

Also, can you confirm that your files aren't corrupted in some way?

/Volumes/Indy Fate % openssl md5 ATLANTIS.* 'iMuse Setups'  'iMuse Setups'/..namedfork/rsrc 
MD5(ATLANTIS.000)= 1a6e5ae2777a6a33f06ffc0226210934
MD5(ATLANTIS.001)= 03e3e717d2bf2ee42fff796db50cb69f
MD5(iMuse Setups)= d41d8cd98f00b204e9800998ecf8427e
MD5(iMuse Setups/..namedfork/rsrc)= 5cabc6c7ad3cd04d8dbd4a47c481d019

/Volumes/Indy Fate % ls -dl ATLANTIS.* 'iMuse Setups'  'iMuse Setups'/..namedfork/rsrc
-rwxr-xr-x@ 1 prh  staff    11885 Jan  3  1994 ATLANTIS.000*
-rwxr-xr-x@ 1 prh  staff  8782535 Jan  3  1994 ATLANTIS.001*
-rwxr-xr-x@ 1 prh  staff        0 Oct 13  1992 iMuse Setups*
-rwxr-xr-x  1 prh  staff  1096390 Oct 13  1992 iMuse Setups/..namedfork/rsrc*

The game files are on the CD-ROM volume, converted to HFS+ using impluse (a tool that I wrote: ​https://github.com/boredzo/impluse-hfs ). If it does turn out to be a data corruption issue, that makes things much simpler for me as it means *I* can fix it. 🙂 That said, it's unlikely at this point; through a variety of methods (including hashing where possible and installing Mac OS 9 from a converted CD and then booting off the installation), I've reached a high degree of confidence that impluse's output is right.

I can confirm using impluse list that the original HFS volume has the same sizes for iMuse Setups:

Name	Data size	Rsrc size	Total size
iMuse Setups	0	1,096,390	1,096,390

MD5ing resource forks in Mac OS 9 is rather harder, unfortunately. I can at least confirm that running DeRez on that file produces a listing for a bunch of 'snd ' resources with plausible-looking names, so it seems to be a valid resource fork.

I might try setting up Leopard or something in a VM; then I'll have a VM where I can mount HFS volumes and also run md5 on that resource fork.

[boredzo]

Attached a screenshot of a Mountain Lion VM in which I mounted the original HFS image. MD5 of the iMuse Setup file's resource fork = 5cabc6c7ad3cd04d8dbd4a47c481d019.

Both MD5s match the MD5s I got from that file on the HFS+ conversion. So it's not data corruption.

[dwatteau]

Thank you very much for all the additional details you've provided!

So we have the same ATLANTIS.00* files, but for the resource fork of iMuse Setups I'm getting a different bb1fccf466ab05778e6bf008fd1aad40 MD5 here. Same number of bytes and same modification date, though. That doesn't necessarily means that something is wrong with your file, but it's a bit strange.

Does the Macintosh demo start on your setup?
​https://downloads.scummvm.org/frs/demos/scumm/atlantis-mac-demo.zip

(well I see that this demo has some other problems which need a dedicated issue...)

[boredzo]

I should note, while we're looking at the iMuse Setups file, that music works—including in the original “Fate of Atlantis” application, if I run it in SheepShaver.

I get the same crashes with the demo. 2.6: crash on game start. Same 2.7 build as before: crash on F5.

Finder on Monterey doesn't show the application's version (guess they dropped support for 'vers' resources at some point), but trying it in SheepShaver, I see that my “Fate of Atlantis” application is version 1.5t.

[boredzo]

It might be interesting to try this on your iMuse Setups file: ​https://github.com/boredzo/md5_rsrc

There's an app for Classic Mac OS called Checksum that does MD5 hashes of data and resource forks separately. Its manual notes that part of the resource fork is reserved by the system, and basically suggests that it isn't useful to include that portion in MD5 hashes. Checksum omits that section, substituting zero-bytes instead.

This command-line tool does the same substitution, and I've confirmed that it produces the same hash as Checksum for my iMuse Setups file's resource fork: 9c98f691b3e6e13e874684b24e599fd0.

[dwatteau]

Thanks. That demo does work here (although it'll crash or misbehave if you move too much around, because it's not meant to be an interactive one, but that's another matter), even when pressing F5. So with the same reference you have a crash that I don't have (I'm also running macOS), so the difference triggering it must be somewhere else.

Do you have enabled a particular, non-default sound setting in ScummVM? Otherwise, can you try playing this demo in ScummVM on a non-macOS computer (such as Windows, Linux...) with default settings? The idea is to figure out which setting possibly triggers this.

Thanks.

[boredzo]

The game options are default. I'm less sure about my sound settings; I don't remember whether I've ever changed them. I'll attach my ScummVM Preferences file.

I see 2.7 is out now. No change with the release build.

I tried downloading ScummVM 2.7 on a Linux Mint 20.1 VM, but couldn't satisfy its dependencies. I'm downloading 21.1 and will try that later.

[boredzo]

*I'm less sure about my global sound settings

[dwatteau]

It might be interesting to try this on your iMuse Setups file: ​​https://github.com/boredzo/md5_rsrc
...

Nice tool; I wasn't aware of that behavior, thanks! Well, I confirm that we have the same iMuse Setups resource then.

Thanks for your preferences files; I can reproduce the issue with it, so now it's a matter of finding which precise setting triggers it. Just wait a bit...

[dwatteau]

It looks like this comes from enable_gs=true (MT-32 > Roland GS device) being enabled in your global settings. Disabling it (or only enabling it for the games where it makes sure) appears to solve the problem.

On the other hand, I don't think the app should crash, even if enable_gs doesn't make sense for this game. I'll see if we can get this fixed.

[boredzo]

I can confirm that turning that setting off makes F5 work and not crash.

[dwatteau]

Thanks. And here's a small backtrace with that release and enable_gs=true, in case it can be useful to other developers (I'm won't be able to fix something in that area myself)

(lldb) bt
* thread #1, queue = 'com.apple.main-thread', stop reason = hit program assert
    frame #0: 0x00007ff803d7d00e libsystem_kernel.dylib`__pthread_kill + 10
    frame #1: 0x00007ff803db31ff libsystem_pthread.dylib`pthread_kill + 263
    frame #2: 0x00007ff803cfed24 libsystem_c.dylib`abort + 123
    frame #3: 0x00007ff803cfe0cb libsystem_c.dylib`__assert_rtn + 314
  * frame #4: 0x00000001000be84e scummvm`Scumm::IMuseDriver_MacM68k::send(this=0x0000000102857000, d=31664) at mac_m68k.cpp:116:2
    frame #5: 0x00000001000a8e56 scummvm`Scumm::IMuseInternal::pause(this=0x000000010282f400, paused=true) at imuse.cpp:371:18
    frame #6: 0x000000010017363c scummvm`Scumm::Sound::pauseSounds(this=0x000000010281b800, pause=true) at sound.cpp:1228:16
    frame #7: 0x000000010016c4e3 scummvm`Scumm::ScummEngine::pauseEngineIntern(this=0x0000000128068000, pause=true) at scumm.cpp:3376:12
    frame #8: 0x000000010019a9ac scummvm`Engine::pauseEngine(this=0x0000000128068000) at engine.cpp:661:3
    frame #9: 0x0000000100075fc9 scummvm`Scumm::ScummEngine::showMainMenu(this=0x0000000128068000) at gfx_gui.cpp:1789:18
    frame #10: 0x00000001000c6b8d scummvm`Scumm::ScummEngine::processKeyboard(this=0x0000000128068000, lastKeyHit=(keycode = KEYCODE_F5, ascii = 319, flags = '\0')) at input.cpp:1111:5
    frame #11: 0x00000001000c41b3 scummvm`Scumm::ScummEngine::processInput(this=0x0000000128068000) at input.cpp:484:2
    frame #12: 0x0000000100169f64 scummvm`Scumm::ScummEngine::scummLoop(this=0x0000000128068000, delta=1) at scumm.cpp:2540:2
    frame #13: 0x00000001001698d2 scummvm`Scumm::ScummEngine::go(this=0x0000000128068000) at scumm.cpp:2374:3
    frame #14: 0x000000010016d592 scummvm`Scumm::ScummEngine::run(this=0x0000000128068000) at scumm.h:573:10
    frame #15: 0x000000010001c13a scummvm`runGame(plugin=0x000060000021cee0, enginePlugin=0x000060000021cec0, system=0x0000000101505250, debugLevels=0x00007ff7bfeff810) at main.cpp:319:33
    frame #16: 0x000000010001a510 scummvm`::scummvm_main(argc=1, argv=0x00007ff7bfeff9c0) at main.cpp:806:27
    frame #17: 0x0000000100015a4d scummvm`main(argc=1, argv=0x00007ff7bfeff9c0) at macosx-main.cpp:44:12
    frame #18: 0x00000001009e952e dyld`start + 462

[boredzo]

I can confirm that the crash reproduces on Linux Mint 21.1 with ScummVM 2.7 from Flatpak.

[athrxx]

Thanks for the report. The issue has been fixed (I hope).

[boredzo]

Thanks. I see in the commit history that the fix was ​https://github.com/scummvm/scummvm/commit/7694db025e8a58d8c99321069e862a97b266e78d . I'll grab a nightly in a day or two and let you know.

[dwatteau]

Thank you for the fix athrxx, and thank you for planning on confirming this change with a test, boredzo.

I have tested the change with my own copy of this game now, and it's all good. So I'm going to backport this change for the (probable) 2.7.1 release.

[boredzo]

Verified with:

ScummVM 2.8.0git2647-gd1d9d8f0644 (Mar 14 2023 05:13:09)
Features compiled in: TAINTED Vorbis FLAC MP3 TiMidity RGB zLib MPEG2 FluidSynth Theora AAC A/52 FreeType2 FriBiDi JPEG PNG GIF taskbar TTS cloud (servers, local) ENet SDL2 TinyGL OpenGL (with shaders) OpenGL desktop only RetroWave 

which is the nightly build of [d1d9d8f0] on Monterey, with both the demo and with my CD of atlantis-mac. This is fixed.

[boredzo]

Thank you both!