We haven't been able to reproduce this crash yet, unfortunately
For those seeing the crashes, what version OS version are you currently running? (I'm assuming it's 1.13.7, but just in case)
Would someone with a crashing device mind sending me a copy of the Heavy Drinker game on their device? I can't think of a reason it would be different than the sideloaded game on my test devices, but I just want to cover all my bases.
(Just for the record, this does seem like an OS bug, not something that is the fault of Heavy Drinker or @intellikat, though I would be very curious to hear if the shortened bundleID fixes the problem for anyone!)
Here’s the game as it was installed on my device, copied out of /Games/User and zipped on my Mac. Device was running 1.13.7 and didn’t start crashing until after I loaded another game that I was working on using the simulator, which I wrote about in this other thread where I also posted crash logs
Hi it's seem that my entry for the PlayJam 3 had created someone who test with device and had the same error (the looping) but i don't have the error log to share you...
Here's the build :
UPDATE : I remove the build from this post, my tester had also heavy drinker, you might be able to find it on the playjam3 page ...
Glad if it could help...
I don't have my device for testing myself...
I sideloaded that old original file via play.date website two days ago and then in settings>games the playdate crashed and kept crashing till deleting the gamefile and doing the recovery combo like explained above. I dont want to try that again.
It's definitely the long bundleid. Here's the kicker: Dan and I couldn't reproduce it immediately because we have 2-digit user ids in WOPR and that wasn't quite enough to trigger the problem. The json encoder has a function that adds the necessary backslash and \u quoting to the input data, first counting up how much space it'll need then either using the stack if it's <= 128 characters or using malloc() if not. So in our case it was using a stack buffer, for everyone else the heap. Next, a while back I added escaping to the forward slash as required by json but forgot to add it to the count. So we have an out of bounds write there, which doesn't do anything terrible on the stack but really messes up the heap here because it's system heap using newlib's allocator which stores block data at the start of blocks--an out of bounds write blows away the next block's info and causes all sorts of trouble. For game heap we're using dlmalloc which stores block info in a separate struct.
I'll get an MR in ASAP and hopefully we can get a patch release out soon. Sorry for the trouble!
I don't seem to be able to get past #7 from @daprice's recipe above.
I.e. I can load the recovery firmware, manage to lock the screen before it crashes (have to be very quick), wait for the "Update Available" to show, but I cannot then manage to get to the update installer.
I note that there is an option to update the firmware from within the simulation - @dave or @dan is it possible to get a copy of the 1.13.7 firmware to load this way?
Yes, we should be able to get that to you. If you could reach out via the form at the bottom of https://help.play.date, someone should be able to help you out (they are expecting your message, but if you don't hear back soon let me know and I'll follow up!).
