Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Debuggers are not killed when vscode server exits after connection loss #1393

Open
smokeysa opened this issue Apr 4, 2023 · 0 comments
Open

Comments

@smokeysa
Copy link

smokeysa commented Apr 4, 2023

VSCode version: 1.77.0
Remote extensions: Last updated 4/3/2023, 08:35:51
Platform: Linux local/Linux remote

To reproduce -- setup:

  1. Have a remote machine that you can break connectivity to, e.g. a cloud machine.
  2. Build a "hello world" executable with debug info in it on the remote machine (gcc -g hello.c -o hello).
  3. Connect to the remote machine using vscode remote extensions and open a folder.
  4. Install cpptools extension pack on the remote machine

To reproduce the bug:

  1. Set up a (gdb) Launch configuration for the "hello world" application.
  2. Set a breakpoint on main
  3. Start the debugging session. Debugger should be stopped at main.
  4. Break the connection (e.g. turn off internet access)
  5. Close vscode window

On the remote machine, all the processes are still running as expected. The vscode server processes will keep running for 8 hours and then close.
However, when they do exit, they leave the following process tree still running (each line is the child of the preceding line).

ubuntu      5323  0.0  0.0  10008  5048 pts/9    Ss   08:49   0:00 /usr/bin/bash
ubuntu      5339  0.0  0.0   2616   596 pts/9    S+   08:49   0:00 /bin/sh /tmp/Microsoft-MIEngine-Cmd-houwzgwd.xfk
ubuntu      5341  0.1  0.5  60332 48032 pts/9    S    08:49   0:00 /usr/bin/gdb --interpreter=mi --tty=/dev/pts/9

PID 5323 (/usr/bin/bash) was reparented to 1.

There is no way to kill these except to manually do it on the remote machine, and there's no reason for a user to expect to have to do this. For gdb this doesn't matter too much, but our situation is one of a third party debugger that will have checked out a license from a limited pool. It will hold this license forever.

I have genuinely reproduced this by waiting for 8 hours -- however, it is also possible to reproduce the same behaviour immediately after step 5 by:

  1. Re-establish connectivity on local machine.
  2. Use command "Remote-ssh: Kill vs code server on host" to kill the server.

I think that vscode server should destroy the debug session when it exits.

Files

hello.c:

#include <stdio.h>

int main(void)
{
    printf("hello world!\n");
}

launch.json:

{
    // Use IntelliSense to learn about possible attributes.
    // Hover to view descriptions of existing attributes.
    // For more information, visit: https://go.microsoft.com/fwlink/?linkid=830387
    "version": "0.2.0",
    "configurations": [
        {
            "name": "(gdb) Launch",
            "type": "cppdbg",
            "request": "launch",
            "program": "${workspaceFolder}/hello",
            "args": [],
            "stopAtEntry": false,
            "cwd": "${fileDirname}",
            "environment": [],
            "externalConsole": false,
            "MIMode": "gdb",
            "setupCommands": [
                {
                    "description": "Enable pretty-printing for gdb",
                    "text": "-enable-pretty-printing",
                    "ignoreFailures": true
                },
                {
                    "description": "Set Disassembly Flavor to Intel",
                    "text": "-gdb-set disassembly-flavor intel",
                    "ignoreFailures": true
                }
            ]
        }
    ]
}
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant