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
VSCode version: 1.77.0
Remote extensions: Last updated 4/3/2023, 08:35:51
Platform: Linux local/Linux remote
To reproduce -- setup:
Have a remote machine that you can break connectivity to, e.g. a cloud machine.
Build a "hello world" executable with debug info in it on the remote machine (gcc -g hello.c -o hello).
Connect to the remote machine using vscode remote extensions and open a folder.
Install cpptools extension pack on the remote machine
To reproduce the bug:
Set up a (gdb) Launch configuration for the "hello world" application.
Set a breakpoint on main
Start the debugging session. Debugger should be stopped at main.
Break the connection (e.g. turn off internet access)
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).
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:
Re-establish connectivity on local machine.
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
}
]
}
]
}
VSCode version: 1.77.0 Remote extensions: Last updated 4/3/2023, 08:35:51 Platform: Linux local/Linux remote
To reproduce -- setup:
gcc -g hello.c -o hello
).To reproduce the bug:
(gdb) Launch
configuration for the "hello world" application.main
main
.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).
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:
I think that vscode server should destroy the debug session when it exits.
Files
hello.c:
launch.json: