E0 crash shortly after launch, requires factory reset

SDK Bug Reports
1

This issue is completely blocking me from testing on device. I've dealt with seemingly random crashes when building on macOS for a while, but never so persistently and never on Windows. I cannot figure out what is triggering the crashes, but they began shortly after:

  • I upgraded to 2.0.0
  • I started using pd.sound.fileplayer to play WAV files up to 10 MB in size.

Help would be very much appreciated <3

Technical specifications

SDK/firmware: 2.0.0

platforms:

  • v1 Playdate (Playdate PDU-Y-01)
  • m2 macOS Ventura 13.3.1
  • Windows 10 Pro v22H2

connection: direct USB C-C

My hunch is that the issue arises from the macOS build, but once the crash occurs once, subsequent Windows builds will fail as well.

Steps to reproduce:

Two similar commits were chosen below, but this should be reproducible with more-or-less any commits in that branch made in the last few weeks.

"The app works" == "You can press A to exit the splash screen into the main menu with the big number in the top-left, the floating buttons to the right of it, etc."

  1. On Mac, clone, build, and run this commit in the Playdate simulator. The app should work.
  2. Upload the app to the Playdate device and run it. It should work.
  3. On Mac, clone, build, and run this subsequent commit (changes are to some sound files) in the Playdate simulator. It should work.
  4. Upload the app to the Playdate device and run it.

Expected result:

  • Computer waits for playdate disk, copies main.pdx over, unmounts the data disk, and runs the app.
  • The app works, pressing A takes user from splash screen to main menu, etc.

Actual result:

  • Computer waits for the playdate disk, but doesn’t seem to copy any files over, instead skipping straight to unmounting the data disk and then running the app.
  • The app loads the splash screen, but then crashes after a second with an e0 error.
  • Subsequent attempts to run the app from the device menu also fail early with e0.
  • On the error screen, there is no prompt to press B for further information, nor any error logs found in the Playdate data disk.

Attempted fixes:

  • Rebooting: doesn't fix the issue.
  • Booting to the data disk and manually transferring main.pdx: doesn’t fix the issue.
  • Booting to recovery mode: doesn't fix the issue.
  • Factory-reset: temporarily fixes the issue; steps #1-2 work but #3-4 cause crash again.

Crash logs:

— m2 macOS Ventura 13.3.1 —

build:d0114b2d74cd-2.0.0-release.155213-buildbot
r0:20031834 r1:00000000 r2:00001000 r3: 00000400
r12:00003fe0 lr:0803df63 pc:0803ed0c psr: 81000200
cfsr:00000082 hfsr:00000000 mmfar:fffffffb bfar: fffffffb
rcccsr:00000000
heap allocated: 1275968
Lua totalbytes=370358 GCdebt=-2000 GCestimate=367506 stacksize=42

— Windows 10 Pro v22H2 —

build:d0114b2d74cd-2.0.0-release.155213-buildbot
r0:00000001 r1:00000001 r2:00045400 r3: 40012c00
r12:00003fe0 lr:08035583 pc:08035538 psr: 21000000
cfsr:00000082 hfsr:00000000 mmfar:fffffffb bfar: fffffffb
rcccsr:00000000
heap allocated: 1276000
Lua totalbytes=370554 GCdebt=-2000 GCestimate=367698 stacksize=42

3 Likes
3

Updates:

  • Removing each block in my pd.update code did nothing to ameliorate the crashes.
  • I thought that something in the build process was causing the crashes, since they mostly occur ~5 seconds into running the application after build, but this is not the case. One time, my application was working fine for ~5 minutes, then crashed, and continued crashing on subsequent restarts.
  • Crashes occur around frames 24-26.
  • I'm not having this problem with other applications on my Playdate (tested Whitewater Wipeout, Crankin's Time Travel Adventure, Boogie Loops).

I'm not sure what other information I can provide that would be useful.
Here are some crash logs for subsequent crashes on a single build (macOS):

--- crash at 2023/07/05 16:23:50---
build:d0114b2d74cd-2.0.0-release.155213-buildbot
   r0:40012c00    r1:0000000d     r2:00001388    r3: 00000400
  r12:006d3000    lr:0803c791     pc:0803c308   psr: 01000000
 cfsr:00000082  hfsr:00000000  mmfar:000000cc  bfar: 000000cc
rcccsr:00000000
heap allocated: 1751040
Lua totalbytes=376565 GCdebt=-2000 GCestimate=368748 stacksize=42

--- crash at 2023/07/05 16:24:00---
build:d0114b2d74cd-2.0.0-release.155213-buildbot
   r0:00000000    r1:00000000     r2:00030d0e    r3: 00000000
  r12:006d3000    lr:080352cb     pc:08034fd6   psr: 61000000
 cfsr:00000082  hfsr:00000000  mmfar:000000cc  bfar: 000000cc
rcccsr:00000000
heap allocated: 1751040
Lua totalbytes=376565 GCdebt=-2000 GCestimate=368748 stacksize=42

--- crash at 2023/07/05 16:24:08---
build:d0114b2d74cd-2.0.0-release.155213-buildbot
   r0:20002464    r1:00000000     r2:000000ff    r3: 0000003f
  r12:00000000    lr:08044127     pc:0803ed0c   psr: 81000200
 cfsr:00000082  hfsr:00000000  mmfar:000000cc  bfar: 000000cc
rcccsr:00000000
heap allocated: 1749856
Lua totalbytes=375840 GCdebt=-2000 GCestimate=368620 stacksize=42

I'm in the final couple weeks of development on my app, supposed to be tuning sounds etc. on device, completely blocked by these crashes. Would it be possible for me to get access to the 1.13.7 firmware so that I can continue my work while I help you diagnose this?

4

Found it! Turns out if you create an empty image table and don't set all the images the uninitialized data can lead to a crash when the image table is deallocated. In your case it's the 1-cell table in renderDrawable() causing the problem. If you add

imagetable:setImage(1, gfx.image.new(1,1))

right after creating it, that'll fix the problem. Or if you don't want to have that tiny bit of memory churn you could make a global placeholder image and use that instead.

I've got a fix in the queue for this. Thanks for digging this one up, and apologies it took me so long to get back to you! We've got a lot of work right now and not enough people to do it. :sweat:

2 Likes
5

!!!
Thank you so much!

I'm sorry to hear about the busyness. For what it's worth, I'm very happy with this timing! Thank you for your hard work.

1 Like