Diagnosing a possibly sound-related or timer-related crash in Spatterlight (Glulx)

Someone reported that Spatterlight crashed during a Glulx game. Based on the transcript, I think this happened after an action that prompted a sound to play. A Glulx timer may have been involved as well. Apparently, the person was asked to send crash details to Apple.

What can I do about this? Are there particular questions I should ask to try to figure out what’s going on?

You can ask them to locate the crash report on their Mac and send it to you.

https://appleinsider.com/inside/macos/tips/how-to-understand-macos-finder-crash-report-alerts

The file is JSON, but you can dig through and find the stack trace that crashed.

This is more about debugging Spatterlight than debugging your game, thoiugh.

1 Like

It is probably best to report Spatterlight bugs at the Github repository directly here:
https://github.com/angstsmurf/spatterlight/issues

I’ve never really thought about the existence of App Store crash reports before. Looking at the reported crashes for Spatterlight now, I can only find three in the last year, all happening in the Thumbnailer extension (which creates icons for related game files), and also they look more like slow threads killed by the system than actual crashes.

EDIT: Looking closer, it seems to be a little more complicated than that, but still not actual crashes.

Ok, so this is a Spatterlight bug rather than a bug in the game?

What information would you want to have in the bug report?

Apart from the stack trace, the Glulx game file and steps to reproduce the crash would be helpful.

Crashing the interpreter is always an interpreter bug! It may also be a game bug (e.g., the interpreter crashed trying to handle a game bug.)

1 Like

If it crashes Spatterlight, but doesn’t crash another interpreter…should I still be looking for a bug in the game?

It’s worth looking into.

Once you nail down the exact situation that crashed Spatterlight, you should at least replicate that situation in other interpreters and see if they display an error or warning.

1 Like

I submitted a bug report with the crash diagnostics JSON, but I haven’t managed to reproduce the crash yet. Once I get it to reproduce, I can submit the glulx (if @bg approves).

If I’m reading the log right, it crashed at

SFB::Audio::RingBuffer::WriteAudio(AudioBufferList const*, unsigned long) + 216

Perhaps it is better to move this discussion to Github.

As I wrote over there, the crash seems to happen in the SFBAudioEngine library, which I am not very familiar with. Without a way to reproduce it, this is almost impossible to debug.

Spatterlight uses an old version of the SFBAudioEngine library, and perhaps it is time to update it. However, without a way to reproduce the crash, there is no way of telling if that fixes it.

1 Like