- [solved] latest runme crash with stack=0 when loading the title screen
- runme triggers a crash of desmume-cli, version 0.9.11 when –cflash-path is used to grant access to data items
- same runme can be launched when no –cflash-path is provided
- same runme works fine when emulated on old desmume (0.9.6, 32-bit, running on old laptop), even with –cflash-path
- same runme crashes when emulated on old desmume (0.9.6) rebuilt on 64-bit system, with –cflash-path
- SchoolTest can read the title screen, but suffers the same “stuck-on-the-title-screen” bug as observed on the Androïd emulator
- desmume 0.9.11 apparently doesn’t emulate bad address / invalid instruction. That’s not going to help.
![](https://pypebros.wordpress.com/wp-content/uploads/2016/12/9500c-bughunt.png?w=320&h=295)
Sounds like there will be some guru meditation in the upcoming weeks…
Si les tests automatiques avaient plutôt bien supporté le passage d’un vieux devkitpro à un plus récent, les outils du type “runMe” et le test du jeu s’en sortent moins bien. Il n’y aura probablement pas de “release Noël” de School Rush …
First step to sort that out would be to make sure I can see last command the parser tried to parse. That should already be mentioned in the “die()” function, but with such a stackless-crash, it is unclear it would be possible to call a function at all.
Second priority will be to figure out whether the “latest devkitpro/libnds-1.5.12” team still properly support the “register exception handler” feature.
Finally, I’ll have to try freshly compiled SchoolTest against my old desmume, just to check where the regression is.
sp = 0 crash is there because some code in GameScript::parseline[case 's'] decided to save sp's value at [sp+0] rather than in a register (as with “g++ 4.5.1”). that's already a bit odd: 'mov r3, r7' (with r7 playing the role of the stackframe base address) could have worked instead of 'ld r3, [r7,0]'. More odd is the fact that for some reason, the value in [sp+0] got trashed and no longer contains sp, but 0. Oddest is that it all happened when almost no code is run (just a call to siscanf), and never occur when there's a .spr file to load…
could be worth investigating with the emulator if I ever manage to reproduce the issue.
Issue happens when requesting an animation that is missing in the .spr file and parsing further (i.e. trying to create a state based on that animation).
LikeLike
sp = 0 crash is there because some code in GameScript::parseline[case 's'] decided to save sp's value at [sp+0] rather than in a register (as with \”g++ 4.5.1\”). that's already a bit odd: 'mov r3, r7' (with r7 playing the role of the stackframe base address) could have worked instead of 'ld r3, [r7,0]'. More odd is the fact that for some reason, the value in [sp+0] got trashed and no longer contains sp, but 0. Oddest is that it all happened when almost no code is run (just a call to siscanf), and never occur when there's a .spr file to load…could be worth investigating with the emulator if I ever manage to reproduce the issue.Issue happens when requesting an animation that is missing in the .spr file and parsing further (i.e. trying to create a state based on that animation).
LikeLike