Unable to set breakpoint or pause on a running application with extended-remote connection debug

[fbs2016]

Bug type: Debugger

Describe the bug

• OS and Version: Ubuntu 20.04
• VS Code Version: 1.56.2
• C/C++ Extension Version: v1.4.1
• Other extensions you installed (and if the issue persists after disabling them):
• A clear and concise description of what the bug is.
  Unable to set breakpoint or pause on a running application with extended-remote connection debug

To Reproduce
Please include a code sample and launch.json configuration.
Source code of hello:
`#include <stdio.h>
#include <unistd.h>
int a = 10000;
int main(){
int i = 0;
while(i < a){
i++;
printf("test \n");
sleep(2);
}

printf("test \n");

}`

launch.json:
` "configurations": [
{
"name": "gcc - Build and debug active file",
"type": "cppdbg",
"request": "launch",
"program": "/folk/bfu/log/hello",
"args": [],
"stopAtEntry": false,
"cwd": ".",
"environment": [],
"debugServerPath": "",
"externalConsole": false,
"MIMode": "gdb",
"setupCommands": [
{
"text": "target extended-remote 192.168.1.20:12345"
},
{
"text": "set remote exec-file /folk/bfu/log/hello"
},
{
"text": "set logging file /folk/bfu/log/gdbClient.log"
},
{
"text": "set logging on"
},
{
"text": "-enable-pretty-printing"
}
],

        "miDebuggerPath": "/usr/bin/gdb",
        "logging": {
            "trace": true,
            "engineLogging": true,
            "traceResponse": true
        }
    }`

Steps to reproduce the behavior:

1. Build source code to file "hello", and put it on host 192.168.1.20 which run gdb server;
2. on host 192.168.1.20, run gdb server "gdbserver --multi --remote-debug --debug-file=gdbServer.log :12345"
3. run hello in VSC using launch configuration in above;
4. Try to set breakpoint on the line "printf(**)", it failed and the breakpoint icon is gray
   <-- C (setBreakpoints-8): {"command":"setBreakpoints","arguments":{"source":{"name":"hello.c","path":"/buildarea/bfu/devcode/testFolder/cPrj/hello.c"},"lines":[8],"breakpoints":[{"line":8}],"sourceModified":false},"type":"request","seq":8}
   --> E (output): {"type":"event","event":"output","body":{"category":"console","output":"1: (7935) Send Event AD7BreakpointErrorEvent\n"},"seq":374}
   1: (7935) Send Event AD7BreakpointErrorEvent
   --> R (setBreakpoints-8): {"type":"response","request_seq":8,"success":true,"command":"setBreakpoints","body":{"breakpoints":[{"id":1,"verified":true,"line":8}]},"seq":376}
   --> E (breakpoint): {"type":"event","event":"breakpoint","body":{"reason":"changed","breakpoint":{"id":1,"verified":false,"message":"Attempting to bind the breakpoint....","line":8}},"seq":378}
5. Click pause in debug menu:
   <-- C (pause-9): {"command":"pause","arguments":{"threadId":1},"type":"request","seq":9}
   --> R (pause-9): {"type":"response","request_seq":9,"success":true,"command":"pause","body":{},"seq":381}

• From the log in gdbserver, set BP or pause the application, gdbserver can't received any information from gdb client.

I also try to parse the message using wireshark, gdbserver doesn't receive any message about the action set BP or pause.

• #Cannot pause debugger on Linux #807 , check this similar bug, it's different as vsc has get response from gdbserver, in my case no response.

• If set breakpoint first then run the application, it works well and it can hit the breakpoint.

• It works well if run gdbserver on localhost like "target extended-remote 127.0.0.1:12345", VSC received signal "SIGTRAP" first when set BP.
  <-- C (setBreakpoints-8): {"command":"setBreakpoints","arguments":{"source":{"name":"hello.c","path":"/buildarea/bfu/devcode/testFolder/cPrj/hello.c"},"lines":[8],"breakpoints":[{"line":8}],"sourceModified":false},"type":"request","seq":8} --> E (output): {"type":"event","event":"output","body":{"category":"console","output":"1: (16377) ->~\"\\nProgram\"\n"},"seq":374} 1: (16377) ->~"\nProgram" --> E (output): {"type":"event","event":"output","body":{"category":"stdout","output":"\nProgram"},"seq":376} Program --> E (output): {"type":"event","event":"output","body":{"category":"console","output":"1: (16377) ->~\" received signal SIGTRAP, Trace/breakpoint trap.\\n\"\n"},"seq":377} 1: (16377) ->~" received signal SIGTRAP, Trace/breakpoint trap.\n" --> E (output): {"type":"event","event":"output","body":{"category":"stdout","output":" received signal SIGTRAP, Trace/breakpoint trap.\n"},"seq":380} received signal SIGTRAP, Trace/breakpoint trap.

[fbs2016]

gdbServer.log
debugConsoleLog.txt
gdbClient.log

[WardenGnaw]

Thank you for reporting this issue. We’ll let you know if we need more information to investigate it.

[fbs2016]

@WardenGnaw
Have any progress? Or is there any guide to setup dev environment to debug it by myself?

[BillPlunkett]

I had similar problems until I set MIDebuggerServerAddress to the ip address:port of the gdb server

[haneefdm]

@fbs2016, I saw your commend on #844. I am not sure what your question is. I will try to help see if there is a better way. I know a lot more about gdb-servers than I did two years ago so, maybe there is a better way in general to handle remote gdb servers.

But, as things stand now, what @BillPlunkett is saying is probably right. If your gdb-server is truly running on a remote machine, then you probably do need to use MIDebuggerServerAddress

If that does not work, let me know and I can look into it.

[fbs2016]

@BillPlunkett @haneefdm Thanks.
Firstly, we launch gdbserver with multi mode "gdbserver --multi ...", the address set in MIDebuggerServerAddress can't support multi mode connection. So I configure setupCommands ""text": "target extended-remote 192.168.1.20:12345"".

Secondly, I put the out file to target using setupCommands "remote put *out" and other commands which depends on remote connection.
In cppdbg launch, if you configure MIDebuggerServerAddress and setupCommands, it run setupCommands first then connect to MIDebuggerServerAddress . Then "remote put" will failed as the connection doesn't established.

Do you have any advice to configure it to support this scenario? Thanks in advance.

[BillPlunkett]

My scenario is quite similar. Here are the steps I use to debug remotely on a raspberry pi: Assuming the following environment variables have been set prior to starting vscode: export GDB_SERVER_USER=pi export GDB_SERVER_PASSWD=raspberry export GDB_SERVER_ADDR=192.168.100.197 export GDB_SERVER_PORT=2001 export GDB_SERVER_SYSROOT=$HOME/raspberrypi/sysroot And gdbserver has been started on the target: sshpass -v -p $GDB_SERVER_PASSWD ssh -t $GDB_SERVER_USER@$GDB_SERVER_ADDR "killall -9 gdbserver; gdbserver --multi :$GDB_SERVER_PORT" This launch configuration works for me: { "name": "(RPi remote gdb) Launch", "type": "cppdbg", "request": "launch", "program": "${workspaceFolder}/obj/test", "cwd": "${workspaceFolder}", "environment": [], "externalConsole": false, "stopAtEntry": true, "targetArchitecture": "arm", "MIMode": "gdb", "miDebuggerPath": "${env:HOME}/bin/cross-pi-gcc-8.3.0-2/bin/arm-linux-gnueabihf-gdb", "MIDebuggerServerAddress": "${env:GDB_SERVER_ADDR}:${env:GDB_SERVER_PORT}", "setupCommands": [ { "description": "Enable pretty-printing for gdb", "text": "-enable-pretty-printing", "ignoreFailures": true }, ], "customLaunchSetupCommands": [ { "text": "file ${workspaceFolder}/obj/test", "description": "set file to debug", "ignoreFailures": false }, { "text": "set sysroot ${env:GDB_SERVER_SYSROOT}", "description": "set sysroot", "ignoreFailures": false }, { "text": "target extended-remote ${env:GDB_SERVER_ADDR}:${env:GDB_SERVER_PORT}", "description": "connect to gdbserver", "ignoreFailures": false }, { "text": "remote put ${workspaceFolder}/obj/test /home/pi/test", "description": "copy exec-file to target", "ignoreFailures": false }, { "text": "set remote exec-file /home/pi/test", "description": "set remote exec-file", "ignoreFailures": false }, { "text": "set args arg1 arg2 arg3", "description": "set cmdline args", "ignoreFailures": false }, { "text": "tbreak main", "description": "set temporary breakpoint @ main()", "ignoreFailures": false } ], "launchCompleteCommand": "exec-run" }

…

On Thu, Sep 2, 2021 at 8:12 PM fbs2016 ***@***.***> wrote: @BillPlunkett <https://github.com/BillPlunkett> @haneefdm <https://github.com/haneefdm> Thanks. Firstly, we launch gdbserver with multi mode "gdbserver --multi ...", the address set in MIDebuggerServerAddress can't support multi mode connection. So I configure setupCommands ""text": "target extended-remote 192.168.1.20:12345"". Secondly, I put the out file to target using setupCommands "remote put *out" and other commands which depends on remote connection. In cppdbg launch, if you configure MIDebuggerServerAddress and setupCommands, it run setupCommands first then connect to MIDebuggerServerAddress . Then "remote put" will failed as the connection doesn't established. Do you have any advice to configure it to support this scenario? Thanks in advance. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#7719 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABLJ2TAJ4NICBZ7EQMOYB3TUAAVI5ANCNFSM465ELAXQ> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.

[fbs2016]

@BillPlunkett
Thanks a lot. It works.
It confused me that "MIDebuggerServerAddress" can work with gdbserver multi mode after replacing "setupCommands" with"customLaunchSetupCommands".
Form the debug console, I just see the connection log of command "target extended-remote xxx" but no log about "MIDebuggerServerAddress", I try to remove the the option "MIDebuggerServerAddress" but it failed.

And another different is that the option "targetArchitecture" must be set, otherwise the launch report err. But it can work before apply your advice as vsc set it as x86 auto.
Thanks

[github-actions]

This issue has been closed automatically because it has not had recent activity.