i'm struggling to understand the firmware update process others have used. since i don't have real hardware yet i've never seen the process...
was heavy drinker distributed just before a firmware update rolled out? any chance the pulp export required that update and so everything was borked until the update was installed? or are users installing heavy drinker on systems with the latest firmware, experiencing issues, shifting to a recovery image, then updating to the current firmware again in order to fix this issue?
Thanks @daprice - I'm struggling a bit on #7, but this looks to be the process.
I might delete all season games later to make the update banner move up as this morning I hit a wall in trying to scroll down below Saturday edition - it's crashing here before I can scroll at all.
Hi @intellikat - it's strange, I don't think anyone knows yet exactly what it is about that PDX which is causing issues with the launcher.
The boot-loop might also only get triggered when this PDX is sideloaded via the play.date website (this is how I installed it).
To help the panic folks debug the cause of the issue, could you say if there was anything unusual at all about your workflow. I.e. did you make any changes to the files in the PDX after exporting them from pulp? And approximately what date did you do the pulp export?
Hm - interesting suggestion @Nnnn, I can certainly see something like that being a potential source of problems if anything in the code is expecting only 64 characters max and gets 74.
And it could also explain why the bug would only affect sideloading via the website - the sideload procedure is what generated user.50181.pulp.intellikatsgeosbeepsnboopsbitflung.heavydrinker2023426.pdx. Had I copied it over USB then I would have had the much shorter Heavy-Drinker-2023.4.26.pdx which could explain why @intellikat's partner wasn't affected?
I took a look at the zip I had downloaded the other day and the bundle id seemed too long to me.
Plus, that there is a file data.json.zip within the pdx, though I don't know if that's normal for a Pulp game.
I mean, i don't know anything about this, but these are the two things I would try changing.
The .json file is by default bundled into the PDX and we left it in here so that it can still be looked at if anyone wants to. The .json file existing in the .zip shouldn't be an issue in itself.
I did shorten the author string length immediately and re-upload once Tim mentioned the possibility.
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!).
