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:
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 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
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?
@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. 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)
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), 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.
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!
@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!
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 
I'll investigate more when the crashes start up again.
), and also trying to debug