Closed dsinecos closed 5 years ago
@dsinecos Can you make sure your binary is up to date by recompiling?
gdb
is showing that it has not bound the breakpoint when we issue a break info
request.:
body=[bkpt={number="2",type="breakpoint",disp="keep",enabled="y",addr="<PENDING>",pending="hello-world.c:5",times="0",original-location="hello-world.c:5"}]}
We set one by default at main
. This is what a correct one looks like:
1: (1137) <-1010-break-insert -f main
1: (1138) ->1010^done,bkpt={number="1",type="breakpoint",disp="keep",enabled="y",addr="0x000000000040052a",at="<main+4>",thread-groups=["i1"],times="0",original-location="main"}
Notice the memory address of the breakpoint as this is how gdb
binds the breakpoint. In the case of your breakpoints, I'm seeing:
1: (1250) <-1011-break-insert -f hello-world.c:5
1: (1250) ->&"No symbol table is loaded. Use the \"file\" command.\n"
1: (1251) ->1011^done,bkpt={number="2",type="breakpoint",disp="keep",enabled="y",addr="<PENDING>",pending="hello-world.c:5",times="0",original-location="hello-world.c:5"}
Which is telling me a few things. First, gdb isn't loading the symbol table. This is usually an indication that debug symbols aren't included, which -g
in your compile flags should be resolving. Second, the address shows as <PENDING>
which means that gdb
can't determine where this breakpoint actually lies and it isn't being bound. This is why its not getting hit but i don't know why gdb
isn't binding the breakpoint.
My suggestion would be to make sure you run the task that you created again or include it in your launch.json
as a preLaunchTask
so it gets run every time you start debugging.
Thanks a lot @pieandcakes.
Problemo solved. I added the preLaunchTask
field to launch.json
to run the task before debugging.
I had this issue due to trying to debug inside a docker container. I had to run the container with:
docker run -it --cap-add=SYS_PTRACE --security-opt seccomp=unconfined
following https://leimao.github.io/blog/Debug-CPP-In-Docker-Container/.
This gives the container access to the system calls needed for gdb. Note there's security implications from allowing the container access to all syscalls.
Type: Debugger Input information below Describe the bug
To Reproduce
hello-world.c
tasks.json
launch.json
Additional context
Logs