Report #3661
"[script:_menu] Script run-time error" when interacting with "boot chimes" menu.
| source | Gloss Doll |
|---|---|
| version | 0.5.5 |
| status | NEW |
| priority | TRI |
| target fix | |
| report date | 2025-09-13 17:32:53 |
| report | First page https://i.imgur.com/1FO5hbL.png Second page: https://i.imgur.com/39h6KnU.png Pressing NEXT > [17:01] : [script:_menu] Script run-time error [17:01] Stack-Heap Collision At first, I was convinced that this was a 100% repeatable error. It happened 3 times in a row.. pressing NEXT > on page 2 would repeatedly cause a stack heap collision. Unfortunately, the 4th time, it didn't. I had the following thoughts as to what might be causing it, as Kaijsa (luminescent.sakura) had suggested it might be a 'still drawing the page' issue (when the pages were clearly finished drawing during the crashes). -- "Maybe it's something 'going on in the background' that I can't see, that's hitting at the same moment.. like you said something about waiting for the page to finish drawing.. but if I play a sound, there's a world where it could be redrawing the whole page identical to what's currently being displayed, but with a different 'most recent sound'.. so while it's redrawing all the text again, I don't see the change, and might be hitting next too soon" "basically like an invisible draw action still running.. that I have no way to detect if I'm hitting the race condition or not. Going from page 1 to page 2.. the draw is visible as it goes down the page.. but if I play "pi2", on page 2, it has to redraw the first line.. it's possible it's reasserting all the existing text on that page, and 'isn't finished'" -- Not sure if this helps, but I was advised to file the report anyways, just in case. |
a year ago
armelthelae:
Some other units have started coming up with a very similar crash to this when interacting with the holomenus of the Arecibo and dax/3. It seems like the menu session state may be coming unsynced when another user goes to operate the menu in some capacity after some time, after a fresh script reset of the controller and a full kernel restart, they can operate the menu fine for a while, but after some time the menu will stackheap the _ctrl script when someone else opens the menu and enters a submenu or attempts to change a setting.