03-16-2023, 09:38 AM
Just started getting a weird and persistent crash when loading a particular setlist on my (Arm64) Surface Pro 9. The new crash (100% repeatable) seemed to start right after an annotation-related crash while copying a section from another page in the same song, so dunno if it's database corruption or what. Backing up and restoring to a fresh DB seems to fix the problem in the fresh copy of the DB (and as far as I can tell, all my state and annotations are intact), but the crash still reproduces fine on the original default DB, if anyone wants logs or anything before I blow it away.
For the broken one:
The crash only occurs with the default settings that load all songs from the setlist when you open one; loading the songs individually outside the setlist seems to be OK. When loading a song from the setlist, one CPU is pegged for a few seconds, the MobileSheets process memory explodes past 2GB, then the process dies. I'm guessing it's running up against the allocation limits of a 32-bit ARM process, but loading the same setlist from the "fixed" copy of the DB only uses a couple hundred megs and has been working fine with this same setlist and songs for several months. I started having the problem today on 3.6.9 during a show (first time I've had to fall back to paper in 4+ years with MobileSheets!); it also still fails the same way under 3.7.2.
Not a fiery-hot issue since restoring to a fresh DB seems to have me working again, but would definitely like to know what's up, and also if there's anything I can do to help get MobileSheets' Windows on ARM performance on-par with Windows on Intel and Android- always seems to be a bit pokier and more unstable there. I've got Windows ARM dev environments laying around- happy to pitch in with some profiling, test builds, whatever. I've been selling people on cheap Windows ARM hardware + MobileSheets in every group I'm in, so thanks for making it a going concern!
For the broken one:
The crash only occurs with the default settings that load all songs from the setlist when you open one; loading the songs individually outside the setlist seems to be OK. When loading a song from the setlist, one CPU is pegged for a few seconds, the MobileSheets process memory explodes past 2GB, then the process dies. I'm guessing it's running up against the allocation limits of a 32-bit ARM process, but loading the same setlist from the "fixed" copy of the DB only uses a couple hundred megs and has been working fine with this same setlist and songs for several months. I started having the problem today on 3.6.9 during a show (first time I've had to fall back to paper in 4+ years with MobileSheets!); it also still fails the same way under 3.7.2.
Not a fiery-hot issue since restoring to a fresh DB seems to have me working again, but would definitely like to know what's up, and also if there's anything I can do to help get MobileSheets' Windows on ARM performance on-par with Windows on Intel and Android- always seems to be a bit pokier and more unstable there. I've got Windows ARM dev environments laying around- happy to pitch in with some profiling, test builds, whatever. I've been selling people on cheap Windows ARM hardware + MobileSheets in every group I'm in, so thanks for making it a going concern!