microsoft / microsoft/MIEngine
Debuggers are not killed when vscode server exits after connection loss
Nobody has claimed this yet.
- Dominant language
- C#
- Stars
- 859
- Forks
- 233
- Avg merge
- 1d 6h
- Merged PRs (30d)
- 3
Description
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) Launchconfiguration 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).
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:
- 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
}
]
}
]
}
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Reproduce the connection-loss scenario using hello.c and launch.json, with the (gdb) Launch configuration described in the issue. Observe the remote process tree after the VS Code window and server exit. Done means the debug session's shell and debugger processes no longer remain running or retain resources such as debugger licenses.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- cpp, csharp, vscode
- Domain
- devtools
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100