E0 crash with Lua game on SDK 2.0


While working on my Lua game I started getting a crash pretty consistently (but always at different times) after upgrading to SDK 2.0. This only seems to happen when testing the game on device, and not in the simulator (which I mostly run on MacOS). EDIT: as mentioned later in the thread, I eventually started seeing this in the simulator as well.

Looking at some of the crash reports (which I've also sent via Settings -> System -> Send Crash Report), and referencing this post by @dave it would appear, if I understand correctly, that the crash happens in firmware code, for example:

--- crash at 2023/06/27 23:55:31---
   r0:00000002    r1:20002313     r2:200023ea    r3: 00000002
  r12:0000000a    lr:080b3031     pc:080b3daa   psr: 61000000
 cfsr:00000082  hfsr:00000000  mmfar:5b14e494  bfar: 5b14e494
heap allocated: 7682112
Lua totalbytes=949649 GCdebt=-2000 GCestimate=937041 stacksize=42

--- crash at 2023/06/28 00:00:43---
   r0:60fe0010    r1:00000000     r2:60fe0410    r3: 60fe0350
  r12:00000006    lr:08022ac1     pc:080b2d9a   psr: 81000000
 cfsr:00000082  hfsr:00000000  mmfar:080eae84  bfar: 080eae84
heap allocated: 7690848
Lua totalbytes=993004 GCdebt=-6768 GCestimate=948234 stacksize=42

Is there anything else I can do to understand more about what could be causing this and debug, given the language I'm using here is Lua rather than C? Or is there anything else that stands out from those crash dumps that I may not be deciphering correctly?

Alternatively, am I able to get the prior firmware 1.13.7 from anywhere, to double check if this is an issue with 2.0 or something I'm causing somehow?

Hi, quick question about this issue, I was wondering if there was any more info logged on the system crash screen? Can you press B to see more info about the call stack?

Unfortunately it doesn't look like it :frowning_face: I should've mentioned that this generally shows up as an Error e0 so only offers the option to press A to reboot and the Error e0 URL. Hence my puzzlement at the moment as to what might be causing it :frowning_face:

Is this in code you could possibly share with me so I could try debugging this issue further? Of course it would be confidential, etc.

I was hoping to get some pointers to narrow it down to a more easily reproducible case before sharing code. However I'm almost done putting together a demo build for this game, which Panic was going to receive anyway, perhaps that could work when it's ready?

Hi, I'm experiencing a similar issue with my Lua app. It might help to look at these tickets together.

@wildbat Older versions of the SDK can be downloaded from here.

@wade If you want me to move my ticket into this thread and close the new one I started, lmk.

Thanks for this info, interesting that you are seeing issues around fileplayer.

@wildbat are you using the fileplayer api as well?

A demo app would be fine when it’s ready, that should be enough to get some idea of what’s going on.

@wade I'm not using the fileplayer API, as far as audio is concerned I'm using sampleplayer, channels, and instruments with synths and samples. I was having simulator crashes that looked related to channel:removeSource(), which I thought I may have been causing, so I tried removing all calls to both addSource and removeSource to narrow it down and, while that seemed to work around the simulator crashes, it left this console crash exposed. But now I'm wondering if audio may indeed be the pattern that connects all of these.

@pasha thanks, I was hoping to rollback the OS on the Playdate from 2.0 to 1.13.7 for testing (recovery firmware looks to be 1.11.x), but the SDK packages don't include a firmware image, unless I missed it?

@wildbat You're right, I can't find the old firmware either, sorry for misleading.

I'm nottt convinced it actually is the audio. Judging by where the crash occurs in my debug logs, it might be input querying or ui.crankIndicator. Unfortunately my device seems to stop crashing the minute I add new print flags for debugging. :disappointed_relieved: I'll investigate more when the crashes start up again.

Never mind, it doesn't seem to have to do with ui.crankIndicator nor anything else in my pd.update loop. I tried removing each block inside my pd.update code one at a time, and it didn't make a difference, the crash occurred regardless.

@wade Could you interpret either of our crash logs for us? Or follow up with any other updates?

I was experiencing mysterious e0 crashes on device after opening the system menu and then transitioning scenes in my game. It could be minutes later - if I transitioned after opening the system menu at any point, the Playdate would crash.

My game makes heavy use of sample players, has 4 audio channels, several effects, etc

The fix for me was to ensure all my sound sources were stopped playdate.sound.sampleplayer:stop() and all of my channels were removed from the global list playdate.sound.channel:remove() before adding any new channels

Prior to finding the solution, I ruled out any garbage collection issues by turning the collector off playdate.setCollectsGarbage(false)

Example crash log:
--- crash at 2023/12/16 06:02:41---
r0:60077f48 r1:20040ea8 r2:00000000 r3: 00000100
r12:00000100 lr:08085b1d pc:00000000 psr: 28000000
cfsr:00000001 hfsr:00000000 mmfar:00000000 bfar: 00000000
heap allocated: 1640864
Lua totalbytes=0 GCdebt=0 GCestimate=0 stacksize=0

1 Like

Very interesting... mine also happens after transitioning scenes, I don't think it's related to the system menu, but we might be doing similar things there. I'm certain I was always stopping the sound sources, but I hadn't tried removing the channels altogether. It happened infrequently enough that I didn't go very far in narrowing it down after these posts, and I had to take a short break from development for other reasons, but I'll definitely give the channels another shake and pair that with some more GC research. Thanks for the tip!

Ok, so after looking into your suggestions with renewed interest and with SDK 2.1.1 (thanks again for the pointers @professir :pray:), and also trying to debug Copying a sample-based synth produces distorted sound, I think this crash is related to the latter bug.

At first, toggling the garbage collector off or removing the channels (and, I assume, recreating them afterwards with channel.new(), since I didn't see a different way to add them back to the global list) did not seem to make a difference for this crash. As I mentioned I was already stopping all sound sources, so that didn't seem to be the problem either.

Then, narrowing down the repro steps for the above bug I had a breakthrough. Turns out that when loading a new music track for transitioning to a new level I was setting up instruments and, for polyphonic tracks, adding multiple voices with copies of the same synth; on repeating these steps for the next level, I would simply create a new instrument with the plain instrument.new(), add voices the same way, then add the new instrument as a source to one of my channels (which made your suggestion of removing channels sound (no pun intended) very promising). Eventually this would make the OS crash, and this ended up happening in the simulator as well, despite my initial analysis indicating the contrary.

With the workaround from the bug above of creating a new synth for each voice, even with the same sample data, this crash seems to disappear. Back when this started happening the cause wasn't obvious to me at all, but getting distorted sound when copying synths showed that something was very wrong -- turns out there may be more going wrong with that synth copy than I first thought.

Perhaps this new information will be helpful for @wade or @dave or others who may want to take a look at what is happening in firmware code around synth copying.

EDIT: I've renamed this thread to make it clear this was no longer device-only.

1 Like

This is interesting, do you happen to have a snippet of code showing what you were doing to cause the issue compared to what you're doing now? That would be helpful for me to try reproduce the issue on my end. Thanks

I was able to pin down the issue with Synth copy, which will be fixed in a future version of the SDK. In the meantime if you avoid using that function you shouldn't have any troubles. Thanks for the additional info, it was very helpful.


Great, glad that was useful! Thanks for looking into it. It sounds like you got all you needed, but in case an extra testbed could be useful I wanted to add that running the snippet from Copying a sample-based synth produces distorted sound in a loop seems to be enough to trigger this (and is a good summary of what was happening in my game over the course of a few levels). Alternatively, if you guys still have the build that I had sent Arisa last August (which I hoped would reach you!), it also was still affected by this and could be another way to verify (though you'd have to play through at least the first 3 levels). Regardless, I'm happy if this got sorted out!

I believe we have this fixed in 2.3, fyi. Please let us know if you're still hitting this bug!

@dave unfortunately even with 2.3.0, in simulator and on device, both my repro snippet and my game continue to crash in the same way. The synth distortion issue is also still present.

Got it, thanks for the sanity check. I got this one confused with a different bug, apparently. I ran your demo (thanks for that, too!) and see the problem. I'll get this fixed first thing in the morning!

1 Like