microsoft / MIEngine

The Visual Studio MI Debug Engine ("MIEngine") provides an open-source Visual Studio Debugger extension that works with MI-enabled debuggers such as gdb and lldb.
MIT License
818 stars 218 forks source link

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

Open smokeysa opened 1 year ago

smokeysa commented 1 year ago

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
                }
            ]
        }
    ]
}