[gdbserver] Detach when stopping debugging when using gdbserver

[LaPeste]

In our setup we have multiple remote C/C++ applications running on various VMs (like many other projects). I'm working on making possible to remote debug these applications with VSCode (by attaching, not launching) . So far I managed to get everything working but 1 very important detail: it's very important that the remote application isn't killed when I stop the debugger (GDB, to be precise). This is because there are many setups scripts that are run on those applications and we can't re-run all of them every time we end a debugging session.

Is there any way to modify what gdb does at closing time? Ideally, I'd like to first detach the application from GDB and then exit GDB, which is what anyone would do to avoid the killing of the application.

I couldn't find any documentation, issues or unofficial guides regarding this.

Thank you in advance.

[pieandcakes]

@LaPeste If you are attaching, you should see the detach button in VS Code. that you can press to detach. Our current behavior is to detach if possible.

If you are not seeing this behavior, please enable traceResponse and engineLogging. You can either post it here or email me directly.

Also a repro example would be helpful for us to see when it doesn't work. My basic hello world loop app does detach.

[LaPeste]

By your wording, I think I understand the problem. I must have not configured properly my launch.json but the official doc doesn't help. I explain better:

The app is running remotely, but, for I don't know what reasons, I can get my local VSCode to attach only if "request" is set to "launch". I didn't want to give much thought into it, since it was just working. I just thought it was... the way it was meant to be used when in remote debugging.

Now, by the way you're saying the problem should be exactly there. I "launch" (although it isn't true, because I'm actually just attaching checking by the PID), instead of attaching. So ending a "launch" session means killing the process.

Getting to what maybe it's the real problem: what's the way to set to attach remotely? My problem:

• If I attach with "miDebuggerServerAddress", then I get the following error: "attach: unable to parse the process id"
• If I then add "processId" with the pick option... I don't know what I'm looking at. It doesn't seem to be the processes of the remote machine, but rather of the local machine.
  • and of course if I additionally hand write in the "processId" the remote PID of interest, I get: "attach: 'processId' cannot be used with miDebuggerServerAddress" which is something I would never have expected to read since to attach I need to tell it to what PID.

Now, I'll tell you the full setup, just to make sure you have all the picture:

• VSCode is installed on: local win10 BUT: VSCode is remotely connect to a local red hat VM.
• the remote applications are running in remote red hat VMs.

(By the way, the PIDs that I'm shown by the "pick process id" I think come from the local red hat VM)

I know it's a wall of text and maybe I didn't even manage to explain myself well enough. So feel very much free to ask extra details or clarifications.

Thanks.

[pieandcakes]

@LaPeste So to clarify, when you "attach" with "type": "launch" you are using gdb<->gdbserver. That isn't a scenario we have looked at to support disconnect so we can investigate it.

Unfortunately with the process picker, it picks either the local process or if you use pipeTransport, the remote process to attach to. With gdbserver i don't think that works as you have to have already started gdbserver to attach.

I'll change the title to better reflect the request.

[LaPeste]

@pieandcakes I precisely "attach" with "type": "launch" with the gdbserver. Sorry for not having mentioned it earlier. We'd love to have the possibility to disconnect instead of killing the application.

I'll investigate in this pipeTransport. Maybe, it could work since the gdbserver on the remote machine is started by a "preLaunchTask".

I may ask you more questions about this pipeTransport later on. For now thank you very much for the support and let me know if you decide to investigate the possibility of disconnecting when debugging remotely.

[pieandcakes]

I think the question would be whether we can tell from gdb <-> gdbserver that the gdbserver instance was an attach and then if so, issue a detach instead.

For now, the easy option would be to allow an additional parameter to allow detach.

[LaPeste]

And do you think it'd take too much to implement the support for this additional parameter? Or are you hinting that's something I can get done on my side?

[pieandcakes]

I'm leaving notes to solve the problem. I don't have time right now to do it. If you would like to contribute that would probably be the quickest way. Otherwise I'll investigate when I have time.

[LaPeste]

I understand. I doubt I'll get to do it, unfortunately. But of course, I'll let you know if that happens. In the meanwhile, thank you for the support so far and let me know here if there are news.

[crazycliffy]

I also have the same problem as @LaPeste . Currently to prevent me from killing the process on the target machine, in VSCode's debug console I have to type "-exec detach" which will stop it gracefully. If there is a way to upvote this feature support, let me know and I'll do it.

[rollebolle]

I am having the exact same issue as @LaPeste . Would love to see this feature implemented

[joeabreu]

I have this exact issue too, connecting to an already running and attached gdbserver, requires a "launch" but stopping the debug session terminates the app, but I only want to detach.

[yoniab93]

Hi. I'm facing this exact issue too. I'm using "-exec disconnect" in VsCode's Debug Console to stop the GDB instead of the "stop" button.