Thomas Okken wrote: ↑Wed Feb 28, 2018 6:19 am
there seems to be something wrong with the logic that clears the jump targets.
No, the logic that clears the jump targets is OK. The problem is an inconsistency in Didier's state file: the program's lclbl_invalid flag is set, which should only be true if all the local GTO/XEQ targets are clear, and yet there is a GTO whose target is not clear.
The lclbl_invalid flag tells Free42 that it doesn't have to clear the local GTO/XEQ targets when editing takes place. The objective is that you don't want to scan the entire program, clearing those targets, every single time an edit takes place. The flag is set when the targets are cleared, and it is cleared when a local GTO or XEQ is performed, causing its target to be set. Thus, there should never be a GTO or XEQ with a target that is set, while the lclbl_invalid flag is also set. (The lclbl_invalid flag indicates that *all* local GTO/XEQ targets are clear, not just some of them.)
The question, then, is how Didier's DM42 got into this state. I don't have an answer to that, unfortunately.
Considering that this is basic Free42 program editing and execution logic, 13 years old, not previously known to have this kind of problem, I suspect that Didier's DM42 got into this bad state because of a DM42 bug, not a Free42 bug... but until the cause is positively identified, there's no way to be 100% sure.
The question of how to get out of that state is also a bit more complicated than I first thought. This should work: enter GTO 00 LBL 00 anywhere in the program, then BST so you're back on the GTO 00; exit PRGM mode, and press SST to execute the GTO 00. It will find the LBL 00, set the jump target in the GTO 00, and clear the lclbl_invalid flag. Then, go back to PRGM mode, and delete the GTO 00 and LBL 00. Since the lclbl_invalid flag is clear, this will cause all the local GTO/XEQ targets to be cleared, and the program should go back to behaving normally.
Saving the program, clearing it, and then reloading it, will also do the trick.