Repository navigation
breakpoints are not verified when remote debugging over ssh #135
Description
When starting a (gdb) debugging session on the remote over ssh (so specifying the ssh object in the launch.json properly), all of my breakpoints turn into a "Unverified Breakpoint" state... but still work correctly
What does "Unverified Breakpoint" mean? And why are they "Unverified" while they just work, my program breaks correctly on the breakpoints and I can add / remove breakpoints on the fly...
Activity
WebFreak001 commentedon Mar 8, 2018
Unverified means that code-debug sent the debug breakpoint requests but didn't get a response that they were successfully added (pending breakpoints)
It could be that breakpoints there do or don't work. Before you discover more issues, check the list here for some more currently known issues: #129 (comment) (you might as well try to reproduce them)
bblazik commentedon Mar 14, 2018
I have also this problem. I thought that is compilation problem (some flags or whatever) but checked on target and everything works as should. It is strange because I can see whole call stack and break in proper line but can't see any variable. I wondering does it not a problem that I having a different start point. Still, I will try to figure it out, start maybe from gdb args.
ivankravets commentedon Mar 15, 2018
The same for me with remote target. I've not seen this problem with previous VSCode versions. Maybe, they changed something.
Also, there is a big problem. The breakpoints are inserting immediately AFTER
-exec-run. If they insert BEFORE, they are visible via(gdb) info b. This is a random issue.For example,
@WebFreak001 do you have any ideas? Why does extension insert breakpoints after exec?
WebFreak001 commentedon Mar 15, 2018
uh vscode gives me the breakpoints after starting debugging iirc. Plus it needs to work afterwards to dynamically change breakpoints
ivankravets commentedon Mar 16, 2018
@WebFreak001 Who does send a this command
-exec-run?WebFreak001 commentedon Mar 16, 2018
https://github.com/WebFreak001/code-debug/blob/master/src/gdb.ts#L106
ivankravets commentedon Mar 16, 2018
Should we wait when autorun commands will be finished before running? https://github.com/WebFreak001/code-debug/blob/master/src/gdb.ts#L100
WebFreak001 commentedon Mar 16, 2018
it is.
ivankravets commentedon Mar 16, 2018
https://github.com/WebFreak001/code-debug/blob/master/src/backend/mi2/mi2.ts#L737
I don't see any
await/Promise.then(). So,this.miDebugger.start()will be run before end target (microcontroller) is ready for debugging. Am I right?Normally,
autorunwith custom commands for embedded target requires 5-10sec depending on the device (flashing, halting, reseting).WebFreak001 commentedon Mar 16, 2018
it isn't waiting for a response before starting, but it will send all commands in order so they should execute in that order according to the docs
ivankravets commentedon Mar 16, 2018
Ok, you know that better. Do you have any ideas how to resolve the issue with breakpoints?
WebFreak001 commentedon Mar 16, 2018
of course that could be a feature improvement for example for flashing etc, if you want it you can make an issue and/or a PR, shouldn't be too hard, just adding a few things to package.json and to the 3 base debug servers
WebFreak001 commentedon Mar 16, 2018
no idea, would need to check the cause first, I have a feeling I will eventually work on this some more soon anyway