Closed vpyatnitskiy closed 2 months ago
This solves the issue using Linux and Godot 3.5.3
@vpyatnitskiy Thanks for doing the legwork on this.
I quickly tested master
after merging and it looks like killing the child works correctly on Windows using both 3.5
and 4.2
.
This is a follow-up for https://github.com/godotengine/godot-vscode-plugin/pull/613. Both PRs need to be merged for this change to work.
Issue:
On Linux, when debugging session is initiated and then closed from VS Code, the game (i.e. the process being debugged) does not terminate.
Steps to reproduce are as you would expect:
Have a launch configuration for GDScript in VS Code properly set up.
Launch a project with F5.
Switch back to VS Code. Press Shift+F5 to close the debugging session.
The session closes but the project continues running.
Cause:
Similar to https://github.com/godotengine/godot-vscode-plugin/pull/613, the debugger process is started with
shell: true
flag, which causeschild_process.spawn()
to first start a shell process which, in turn, starts the actual debugger. The returned PID is the shell's PID; the debugger runs under a different PID.When a debugging session terminates, the shell PID is killed. However, in Linux, child processes are allowed to persist when their parent is killed, so the debugger process survives.
Contrary to https://github.com/godotengine/godot-vscode-plugin/pull/613, the debugger is not launched with
detached: true
― which means it is also running under its own process group, and is effectively inaccessible to VS Code.Solution:
Add
detached: true
to force both processes to share a process group. Rely on the change from https://github.com/godotengine/godot-vscode-plugin/pull/613 to kill the entire group rather than individual process(es).Other notes:
Unlike https://github.com/godotengine/godot-vscode-plugin/pull/613, this change is not restricted to Linux, and may potentially cause unintended consequences on Windows and/or Mac OS. This shouldn't be the case assuming headless LSP works properly on these platforms, but more extensive testing is necessary.
In case it does cause problems on other platforms, the suggested fix is to set the flag depending on the platform, e.g.
detached: process.platform !== "win32" && process.platform !== "darwin"
or similar.Additionally, Godot 3 integration may need to be tested separately since it uses a separate code path.