OS 3.1.0: consistent e0 crash with current version of Agents of Groove (and presumably others)

,

With 3.1.0 out I’ve received reports of a consistent e0 crash that can be triggered in at least two ways with the currently released version of Agents of Groove, either by successfully completing any level (!) or going back to the mission briefing mid-level. This happens both on device and in the simulator.

Some device crash logs I was able to obtain from the good people who reported this:

--- crash at 2026/07/15 15:43:45---
build:ea1b8dc2-3.1.0-release.209542-gitlab-runner
   r0:00000004    r1:2003a344     r2:0dbd0e0c    r3: 0ab90b20
  r12:60645388    lr:2003a344     pc:08061bfa   psr: 890f0000
 cfsr:00000082  hfsr:00000000  mmfar:0ab90b28  bfar: 0ab90b28
rcccsr:00000000
heap allocated: 8660160
Lua totalbytes=130117889 GCdebt=-127574245 GCestimate=2535285 stacksize=84

--- crash at 2026/07/15 15:47:17---
build:ea1b8dc2-3.1.0-release.209542-gitlab-runner
   r0:00000004    r1:606f1fd8     r2:0dbd0e0c    r3: 0ab90b20
  r12:2003a244    lr:08061b9f     pc:08061bfa   psr: 890f0000
 cfsr:00000082  hfsr:00000000  mmfar:0ab90b28  bfar: 0ab90b28
rcccsr:00000000
heap allocated: 8810080
Lua totalbytes=130123409 GCdebt=-127574125 GCestimate=2541013 stacksize=84

--- crash at 2026/07/15 15:55:42---
build:ea1b8dc2-3.1.0-release.209542-gitlab-runner
   r0:04000000    r1:2003a304     r2:0dbd0e0c    r3: 0ab90b20
  r12:2003a304    lr:08062065     pc:08061bfa   psr: 890f0000
 cfsr:00000082  hfsr:00000000  mmfar:0ab90b28  bfar: 0ab90b28
rcccsr:00000000
heap allocated: 8675872
Lua totalbytes=130128525 GCdebt=-127574101 GCestimate=2534557 stacksize=84

--- crash at 2026/07/15 16:01:28---
build:ea1b8dc2-3.1.0-release.209542-gitlab-runner
   r0:00000400    r1:2003a284     r2:ff88ff98    r3: 003dffe9
  r12:2003a284    lr:08062065     pc:08061bfa   psr: 090f0000
 cfsr:00000082  hfsr:00000000  mmfar:003dfff1  bfar: 003dfff1
rcccsr:00000000
heap allocated: 9132864
Lua totalbytes=130099329 GCdebt=-127574204 GCestimate=2507257 stacksize=84
--- crash at 2026/07/15 16:43:57---
build:ea1b8dc2-3.1.0-release.209542-gitlab-runner
   r0:00000004    r1:602ace78     r2:fc23fc18    r3: fcd8fc8f
  r12:2003a244    lr:08061b9f     pc:08061bfa   psr: 090f0000
 cfsr:00000082  hfsr:00000000  mmfar:fcd8fc97  bfar: fcd8fc97
rcccsr:00000000
heap allocated: 9364960
Lua totalbytes=130129184 GCdebt=-127573940 GCestimate=2546852 stacksize=84

--- crash at 2026/07/15 17:02:06---
build:ea1b8dc2-3.1.0-release.209542-gitlab-runner
   r0:00000004    r1:2003a344     r2:fc23fc18    r3: fcd8fc8f
  r12:6063fb28    lr:2003a344     pc:08061bfa   psr: 090f0000
 cfsr:00000082  hfsr:00000000  mmfar:fcd8fc97  bfar: fcd8fc97
rcccsr:00000000
heap allocated: 9384224
Lua totalbytes=130127073 GCdebt=-127573896 GCestimate=2548045 stacksize=84

--- crash at 2026/07/15 17:04:10---
build:ea1b8dc2-3.1.0-release.209542-gitlab-runner
   r0:00040000    r1:2003a2c4     r2:00010000    r3: 0002fffe
  r12:2003a2c4    lr:08061b9f     pc:08061cb2   psr: 210f0000
 cfsr:00000400  hfsr:40000000  mmfar:00000000  bfar: 00000000
rcccsr:00000000
heap allocated: 9265920
Lua totalbytes=0 GCdebt=0 GCestimate=0 stacksize=0

However, it seems that sometimes there may be an e0 crash on restarting the Playdate after the e0 crash, so it’s unclear if all of these logs refer to the same crash or the follow up one.

Repro steps:

  • start Agents of Groove
  • select Play, select any save slot, select any level if there’s any previous save available (for example, level 2)
  • when the conversation comes up, select “skip dialogue” from the system menu
  • press A on the mission briefing screen to start
  • when the level starts, select Briefing from the system menu to trigger the crash

Alternatively:

  • (optional) on the briefing screen press B to go into Options, then Gameplay, enable Crank Assist Mode, Relaxed Mode, Single Button Mode to make things easier
  • play through the level successfully
  • observe the crash

Any hints on what may be going on?

Turns out this is a bug due to setting the fileplayer buffer size to zero--our code mistakes the NULL return from a realloc() call as an out of memory condition and returns an error flag and doesn't clear the pointer in the struct. Then when the fileplayer is collected it tries to free that pointer again, and crashes. I've got an MR in for that, and in the meantime a workaround is to set the buffer size to a small value > 0 instead.

2 Likes

Thank you so much @dave for helping with this, I’ve sent an update to Catalog with a workaround as suggested.

1 Like