Can not attach to remote pid if pid does not exist locally

[andyneff]

I think this is new in Version 0.9.2.

I've been working on understanding #78 and found out that using processId in your launch.json does not work on remote debugging (using gdbserver) if the pid number you use does not exist on the local machine (even though it does exist on the remote machine).

For example:

{
    "name": "C++ Attach",
    "type": "cppdbg",
    "request": "attach",
    "miDebuggerServerAddress": "myserver:6666",
    "program": "${workspaceRoot}/hello",
    "processId": "13467",
    "linux": {
        "MIMode": "gdb"
    },
    "osx": {
        "MIMode": "lldb"
    },
    "windows": {
        "MIMode": "gdb"
    }
}

Even though pid 13467 exist on myserver, it doesn't exist on my localhost, and so when I run the attach, I get

Error attach: no process with the given id found

However if I make sure that pid number exists (via this trick), I get a little further, and get a different error (which existed in v0.9.1 too)

Unable to start debugging. Attaching to process 13467 with GDB failed because of insufficient privileges with error message 'ptrace: Operation not permitted.'.

I still have to work around a lot of issues (highlighted in #78) to get remote debugging working with cpptools

End result, I can't do remote debugging by pid.

(Spoiler, my end goal is gdb debugging in a docker. This is why remote debugging is so important to me/not checking that the pid exists locally because I'm using a gdb/gdbserver in a docker)

[jacdavis]

You are correct that there is a bug here. If the remote server is set, we shouldn't be doing any validation on the pid / processname.

The second issue (ptrace failing) is quite interesting. It sounds like we're actually trying to do an attach to that fake pid. The normal security policy on many distros is that attach is disallowed unless the debugger is running as root, or the target process is a child process of the debugger.

For the docker case, we eventually plan to use a different transport, called the pipe transport, that will allow you to run all of gdb inside the container with stdin/stdout redirected. This would remove the gdbserver requirement in your scenario, but we aren't quite ready with that functionality yet.

[andyneff]

I came to the same guess/conclusion on the second issue

That's awesome about the docker plan. Currently I'm working on this No that it's working yet, but just letting you know what ideas I'm working on, bascially writing wrappers for gdb that really run docker exec -it {docker_name} gdb But the important limitation to point out there is that because of the first issue and second issue, that the pid not being local causes an issue with that. (hence forcing me to do gdbserver even with docker exec -it)

Look forward to being able to use vscode more!

[jacdavis]

Assigning to myself to fix the attach to remote case.

[andyneff]

@jacdavis Thanks!

Just found out that processName suffers from the same problem. Since processName is undocumented, so I'm not sure how you want to handle it, (I don't know if it's a feature being added or removed.)

But if the processName does not exist locally when trying to debug remotely, it will also check and fail, even though it exists remotely.

[jacdavis]

@andyneff, I am able to debug in this scenario without hitting this bug by using the "launch" configuration instead of the "attach" configuration. (once the miDebugServerAddress property is set, it doesn't really matter if this is a launch or attach, as it is going to do what gdbserver was told.) If you need a work around, here's what I did:

1. Launch my app on machine 1 (launched as pid 12206)
2. sudo gdbserver :1234 --attach 12206
3. start vscode on machine 2 (with matching source and binary for symbols)
4. create new launch options
5. Set program to my app relative to machine 2.
6. set miDebugServerAddress to my machine ip and port number
7. Start debugging.

You are correct that there has been a regression in 0.9.2 of the extension. The attach orofile shouldn't be validating the pid or process name if remote is set. I will fix that momentarily.

Please let me know if this work around doesn't work for you.

[jacdavis]

Andy, I just checked in a fix for this. I will ship in our next release. I believe the work around I listed above will get you unblocked, so I'm closing the issue. Thanks a lot for reporting it.

[csholmq]

@jacdavis Do we really need to specify a pid? What if there is already a GDB server running?

[jacdavis]

@csholmq, not once the fix ships as gdbserver will already be attached. Unfortunately, getting the next update of the extension out has been delayed a bit.

[csholmq]

@jacdavis Great. How much is the delay?

I hope to get some tips (and workarounds) in #78 in the meantime.

[jacdavis]

@cshomq, unfortunately, I don't have a date at this time. Hopefully, not too much longer.

[Burnett01]

//Removed my previous comment as I figured how to use this thing. Jacdavis tutorial is what I use now. (Check above). However, would be nice if vscode could support gdbserver --multi option, as proposed in #78 Because that would allow us to have multiple vscode-editors connected to one gdbserver.