search

openMSX / debugger

31 stars 15 forks source link

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

Open sndpl opened 1 year ago

sndpl commented 1 year ago

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).

image
m9710797 commented 1 year ago

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:

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 commented 1 year ago

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 https://github.com/openMSX/debugger/commit/9766bd546b59f415798f24c5b48719ee2462a2ae.
  • 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 https://github.com/openMSX/debugger/issues/188#issuecomment-1670898848, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABB7XO4C6V56YFL4LC7HMFDXUNDFRANCNFSM6AAAAAA3I3SBI4. You are receiving this because you were mentioned.Message ID: @.***>

mthuurne commented 1 year ago

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 commented 1 year ago 
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:

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

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 commented 1 year ago

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 9766bd546b59f415798f24c5b48719ee2462a2ae.

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 commented 1 year ago

I made a screen recording to illustrate the issue described https://github.com/openMSX/debugger/issues/188#issuecomment-1673055615. The program has 1 breakpoint at the start at C000.

Link to screen recording

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

sdsnatcher commented 1 year ago

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

m9710797 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

@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 commented 12 months ago

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.