[Bug] While stepping through the code break points are added randomly

[sndpl]

I compiled the latest code from github (both openMSX and the debugger) and when I for example place a break point on 0x0100 (DOS) and start with a dos disk it stops at the correct address. But when I step a lot through the code random break points are added, in previous versions this wasn't an issue. Not sure when this started since I was using an other branch from @turbor with the new layout).

[m9710797]

Hi, thanks for the report.
Unfortunately I couldn't reproduce the issue (and then I could not investigate what's going wrong and I don't know how to fix it).

This is what I tried:

• I'm using the debugger git git-id 9766bd5.
• I'm using openMSX git version ac077a05be54 (latest commit on the 'master' branch).
• I start openMSX, let it boot to BASIC.
• I connect the debugger, I break at a random point (so somewhere in the BASIC idle loop).
• I place a breakpoint at the current position (keyboard shortcut F5).
• I open the 'Debug list' window so that I can see which breakpoints are set.
• Next I tried 100s (maybe 1000s) of steps, step-over, step-out, step-back commands.
  • Some by clicking the icons at the top of the debugger window.
  • Some via the menu entries like 'Execute > Step into'.
  • Most via keyboard shortcuts: F7, F8, F11, F12.

But at no point did I see extra breakpoints in the 'Debug list' window. Did I miss something? Can you give me more detailed instructions for how to reproduce this.

Actually I did get an extra breakpoint, when I accidentally pressed F5 instead of F7, but that's user error ;-)

When you get extra breakpoints, do they only appear in the debugger, or also on the openMSX side? To check execute the command "debug list_bp" in the openMSX console.

[turbor]

Hello, just my quick two cents, since I haven't looked into the code recently (read: last few years) but if I remember correctly, executing a step-over would be performed by the debugger by setting a breakpoint on the next address after the current PC instructions and then simply let the emulation run. Once the breakpoint was triggered the debugger would then delete this temporary breakpoint. This way it was a catch-all for simple instructions, call's, djnz's etc. It seems like removing these temporary breakpoints now fail. This corresponds to the screenshot that Sandy posted, since the new breakpoints are directly after a call instructions.

…

On 09-08-2023 10:31, Wouter Vermaelen ***@***.***> wrote: Hi, thanks for the report. Unfortunately I couldn't reproduce the issue (and then I could not investigate what's going wrong and I don't know how to fix it). This is what I tried: * I'm using the debugger git git-id 9766bd5 <9766bd5>. * I'm using openMSX git version ac077a05be54 (latest commit on the 'master' branch). * I start openMSX, let it boot to BASIC. * I connect the debugger, I break at a random point (so somewhere in the BASIC idle loop). * I place a breakpoint at the current position (keyboard shortcut F5). * I open the 'Debug list' window so that I can see which breakpoints are set. * Next I tried 100s (maybe 1000s) of steps, step-over, step-out, step-back commands. o Some by clicking the icons at the top of the debugger window. o Some via the menu entries like 'Execute > Step into'. o Most via keyboard shortcuts: F7, F8, F11, F12. But at no point did I see extra breakpoints in the 'Debug list' window. Did I miss something? Can you give me more detailed instructions for how to reproduce this. Actually I did get an extra breakpoint, when I accidentally pressed F5 instead of F7, but that's user error ;-) When you get extra breakpoints, do they only appear in the debugger, or also on the openMSX side? To check execute the command "debug list_bp" in the openMSX console. — Reply to this email directly, view it on GitHub <#188 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABB7XO4C6V56YFL4LC7HMFDXUNDFRANCNFSM6AAAAAA3I3SBI4>. You are receiving this because you were mentioned.Message ID: ***@***.***>

[mthuurne]

Hello, just my quick two cents, since I haven't looked into the code recently (read: last few years) but if I remember correctly, executing a step-over would be performed by the debugger by setting a breakpoint on the next address after the current PC instructions and then simply let the emulation run. Once the breakpoint was triggered the debugger would then delete this temporary breakpoint. This way it was a catch-all for simple instructions, call's, djnz's etc.

It seems like removing these temporary breakpoints now fail. This corresponds to the screenshot that Sandy posted, since the new breakpoints are directly after a call instructions.

It could either be a bug or a design limitation: if the called routine doesn't return normally, the instruction after the CALL will not get executed and the breakpoint cannot trigger its own cleanup.

Note that there is an ADD HL,SP instruction in the screenshot, so some kind of stack inspection or manipulation is going on.

[m9710797]

It seems like removing these temporary breakpoints now fail. This corresponds to the screenshot that Sandy posted, since the new breakpoints are directly after a call instructions.

Sounds like a plausible hypothesis. But I don't think it's correct. At least I couldn't make it go wrong with the following scenario:

• Break emulation. Step until a CALL instruction is about to be executed.
• Place a breakpoint somewhere inside that to-be-called function.
• Execute a step-over command. This stops at the breakpoint set in the previous step.
• There is NO (temporary) breakpoint left after the CALL instruction. In other words: the temporary breakpoint was successfully removed again.

Looking in the internal implementation of step_over (see share/scripts/_disasm.tcl:244 for details):

• It indeed sets a breakpoint right after the to-be-stepped-over instruction.
• This breakpoint gets removed on the next break. So on any break, not just when that specific breakpoint is hit.

Maybe the problem is still related to turbor's hypothesis. But then the scenario to trigger it will be more complex. And I haven't been able to trigger it.

[gilbertfrancois]

I have a bit of similar issue. When I step through code with F8 (step over), it does not step over a call command, but goes into, like I was pressing F7. Also after that, run does not continue code, but keeps stepping through code line-by-line and the emulator is always in break state. I cannot get it back to normal (running) state.

This is with openMSX 0.19 and debugger at 9766bd5.

However, when I downgrade openMSX to e.g. 0.17 and keep debugger at latest master, all seems to work fine. Maybe the issue has its origin in openMSX, not in the debugger?

[gilbertfrancois]

I made a screen recording to illustrate the issue described #188 (comment). The program has 1 breakpoint at the start at C000.

• From the start, stepping through code with F8
• At call _has_val_in_block, step into with F7, then continue with F8
• Suddenly the debugger steps into function _div8_3, but I pressed F8 (step over)
• after that, the debugger only steps through code line-by-line, even when pressing F9 (run).

Link to screen recording

PS: if the screen recording appears blurry, please download it, instead of using the dropbox online player.

[sdsnatcher]

If it needs more confirmation: I also have been dealing with this bug for some time now.

[m9710797]

I tried many thing, but I still haven't been able to reproduce it :-(
We do know (or strongly suspect) it's a regression in the debugger, not in openMSX.
It might help if someone can bisect exactly which git revision of the debugger introduced this problem.

--

Somewhat unrelated. The debugger application is no longer actively developed. But we'll still do bug fixes like this. The integrated debugger in openMSX itself (on the openMSX 'imgui' branch) is getting fairly usable already. Many of the problems in the current debugger are already solved in the integrated debugger (problems like: docking, automatic update, sprite viewer...). Feel free to give this new debugger a try. And feedback is very welcome.

[gilbertfrancois]

After some more tries, I noticed different behaviour of openmsx 19 + debugger (master) when it is compiled for x86 or arm. I need a bit more time to see if this is really the case or not. Next week I can test on a native intel machine.

@m9710797 how is one step in the PC on the Z80 calculated? Is there somewhere a (hardcoded) mapping between steps on the native CPU and emulated Z80, that might be right for x86_64, but wrong on arm64?

[gilbertfrancois]

@sndpl Question: Did you use "save state" / "load state" between the debug sessions? Like [cmd][s] and/or [cmd][r] to quickly start a new run session with the debugger connected?

[Colpocorto]

I'm experiencing this issue as well; furthermore, I have another issue that could be related to this one. Sometimes, a condition that breaks the execution at every instruction is randomly added. I have to remove it with debug remove_condition cond#xx or the debug list.