Failed to 'continue' debug through gdb attach in vscode while terminal gdb is fine

[kk9265]

hi, i have a problem with remote debugger. this cause by epoll_wait which has a system block return -1 with errno EINTR catched by gdb. In terminal, i can simply input c to skip, but in vscode this cannot work. what can i do ? the same issue as #2283

thx for your attention :)

[pieandcakes]

Can you tell me more about your scenario? Why can't you type input c in the terminal? is that a command to gdb? Can you share an engineLog to confirm that it is the same issue?

[kk9265]

the log enginelog.txt it's true that a exception occurred by epoll_wait, a system block return -1 with errno EINTR which is normal, and also can be found in terminal. The different thing is that in terminal i can input c to continue, but in vscode i cannot. The pic may expland more clearly. in terminal :

in vscode: thank you for your attention :)

[gabeluci]

If those two breakpoints are ones you created, just delete them. (top right of the breakpoints window is an icon to "Delete All Breakpoints")

If you did not create these (or one of them) you can delete them by typing:

-exec delete 1

in the debug console, where 1 is the breakpoint number. Then you can continue.

[gabeluci]

You say that "terminal gdb is fine", but when you try in terminal GDB, are you setting breakpoints before you run, like VS Code is doing? Try this in terminal GDB:

break Main.c:79
break Main.c:87
run

You might find that it fails there too. If it does fail, then I wonder if setting the breakpoints after starting execution works differently. Give that a try:

starti
break Main.c:79
break Main.c:87
continue

[kk9265]

It‘s very really appreciated for your prompt reply! I use the command "gdb attach" for my debuging , which maybe like VS Code doing. It can be fine when you delete all breakpoints, but it happens when you insert a breakpoint in your code. I wonder it's the problem that gdb rise a exception which occurred by epoll_wait, makes vscode insert a breakpoint that cannot be insert, so the continue command is aborted.

[gabeluci]

I see. Still, can you try in GDB directly?

I believe this is more an issue with GDB and your build than with VS Code. VS Code is just telling GDB to set a breakpoint. GDB says "ok, I can do that", then when it comes time to actually mark the breakpoint, GDB reports that it cannot access the memory address where that instruction is.

So you would do something like this from the terminal (where "pid" is the process ID you want to attach to):

gdb /home/xck/FJServer/Trunk/CellServer/bin/cellsvr.so
attach pid
break Main.c:79
break Main.c:87
continue

And see if GDB complains with the same "Cannot access memory at address" error.

You could also try switching up the attach and break lines to see if it makes a difference:

gdb /home/xck/FJServer/Trunk/CellServer/bin/cellsvr.so
break Main.c:79
break Main.c:87
attach pid
continue

In your case, it could have something to do with this warning that's in your log:

.dynamic section for "/home/xck/FJServer/Trunk/CellServer/bin/cellsvr.so" is not at the expected address (wrong library or version mismatch?)

You might want to address that. Getting that warning to disappear might get rid of the breakpoint errors. I'm no expert there, but when searching for that message, I found this that might help.

[github-actions[bot]]

Hey @pieandcakes, this issue might need further attention.

@kk9265, you can help us out by closing this issue if the problem no longer exists, or adding more information.

[github-actions[bot]]

This issue has been closed automatically because it needs more information and has not had recent activity.

[misclicked]

launch.json:

{
    "configurations": [
        {
            "name": "C++ Launch",
            "type": "cppdbg",
            "request": "launch",
            // "program": "something.so",
            "program": "ls",
            "miDebuggerServerAddress": ":1234",
            "cwd": "${workspaceRoot}",
            "stopAtConnect": true,
            "stopAtEntry": true,
            "externalConsole": false,
            "linux": {
                "MIMode": "gdb",
            },
            "logging": { "engineLogging": true }
        }
    ],
    "version": "2.0.0"
}

To me, this only happens when using gdbserver to attach to a shared library, with the program set to the .so file. I think gdb will create two breakpoints, 1 being the physical address in the shared library.

Changing the program to an executable that I'm not currently debugging with will make gdb read the symbol of a dummy file (in this case: reading ls (1: (1012) <-1006-file-exec-and-symbols ls)) before doing 1: (1095) <-1009-target-select remote :1234. Somehow this makes gdb decide not to set a breakpoint on the physical address. And the actual .so symbols will be read after gdb is connected to the remote gdbserver.