Detaching from a parent debugging session leaves a zombie child session

[firelizzard18]

Issue Type: Bug

VS Code version: Code 1.49.3 (2af0510, 2020-10-02T17:54:06.165Z)
OS version: Darwin x64 19.6.0

1. Attach to or launch a debugger that spawns a child process and attaches to the child as a nested debugger session
2. Detach from the parent session
3. The child session stays attached and the debugger toolbar stays active, but the child session disappears from the call stack pane.

I am using vscode-byebug and byebug-dap. I've attached my test ruby file and launch configurations. For attaching, I am running bundle exec byebug-dap -f --wait --unix debug.socket main.rb.

• example.zip

System Info

Item	Value
CPUs	Intel(R) Core(TM) i7-6700HQ CPU @ 2.60GHz (8 x 2600)
GPU Status	2d_canvas: enabled flash_3d: enabled flash_stage3d: enabled flash_stage3d_baseline: enabled gpu_compositing: enabled metal: disabled_off multiple_raster_threads: enabled_on oop_rasterization: enabled opengl: enabled_on protected_video_decode: unavailable_off rasterization: enabled skia_renderer: disabled_off_ok video_decode: enabled webgl: enabled webgl2: enabled
Load (avg)	2, 2, 2
Memory (System)	16.00GB (0.46GB free)
Process Argv	--crash-reporter-id b66d31ed-6df8-483a-9367-cc739cc188f5
Screen Reader	no
VM	0%

Extensions (33)

Extension	Author (truncated)	Version
calculate	aca	2.1.0
Bookmarks	ale	11.3.1
quitcontrol-vscode	art	3.1.3
rails	bun	0.16.7
vscode-gemfile	bun	0.4.0
better-toml	bun	0.3.2
vscode-test-explorer-status-bar	con	1.1.2
vscode-eslint	dba	2.1.8
gitlens	eam	10.2.2
permute-lines	ear	1.1.0
EditorConfig	Edi	0.15.1
vscode-npm-script	eg2	0.3.13
vscode-byebug	eth	0.1.0
vscode-go-test-adapter	eth	0.1.3
vscode-firefox-debug	fir	2.9.1
gitlab-workflow	Git	3.3.0
go	gol	0.17.2
vscode-graphql	Gra	0.3.10
vscode-test-explorer	hbe	2.19.1
docomment	k--	0.1.18
cpptools	ms-	1.0.1
hexeditor	ms-	1.3.0
vsliveshare	ms-	1.0.2902
vsliveshare-audio	ms-	0.1.91
vsliveshare-pack	ms-	0.4.0
debugger-for-chrome	msj	4.12.11
material-icon-theme	PKi	4.3.0
ruby	reb	0.27.0
slim	sia	0.1.2
rewrap	stk	1.13.0
code-spell-checker	str	1.9.2
haml	vay	1.0.1
vscode-ruby	win	0.27.0

[vscodebot]

(Experimental duplicate detection)
Thanks for submitting this issue. Please also check if it is already covered by an existing one, like:

• Provide a way to specify controlling debug session in multi-session scenarios (#101140)

[connor4312]

It's expected that the child session will send a terminated even when it exits. If this is not the case then I believe VS Code will be in the state that you show. Are you able to determine whether this is what you're running into?

[firelizzard18]

In this case, a long-running process with worker process children is running. When VSCode attaches to the main process, the debug adapter informs the extension of the children (via a custom event), and VSCode attaches to the children, as child debug sessions. When VSCode disconnects from a given session, the process/debug adapter (intentionally) does not exit.

This appears to be a side-effect of the fact that VSCode leaves the Call Stack view empty if there is only a single debug session, which is single threaded. If I start a second thread in the child, the two threads appear in the Call Stack view. I still find this behavior confusing, but I guess it's not a bug. I might open a feature request: "VSCode should show something in the Call Stack view for a single, single-threaded debug session."

[connor4312]

Ah, yea. The call stack is empty when not paused and with a single session. That's as designed at the moment, but is now different than what the js debugger does for instance (since the js debugger uses a logical parent session). Forwarding to Isi for thoughts.

[isidorn]

Correct this is designed. Call Stack is empty when not paused and with a single session.
However I agree it is confusing so I have pushed a commit to improve this. Namely we will show a RUNNING label in the CALL STACK header area when there is a single session running. Try it out with VS Code insiders from tomorrow and let us know what you think.

Alternative is to show the session in this case, however then the UI might be jumping too much when a breakpoint gets hit (where did my session go).