"autoAttachChildProcesses": true doesn't work in Windows with "type": "extensionHost"

[segevfiner]

Describe the bug
A clear and concise description of what the bug is.

To Reproduce
Steps to reproduce the behavior:

1. Create a new VS Code "Extension - TS" project.
2. Modify its "launch.json" to include "autoAttachChildProcesses": true.
3. Add launching a long running node child process via child_process to the extension.
4. The child process won't be debugged. In fact, any node child process started by the VS Code Extension Development Host won't be debugged.

Such process are debugged correctly when I do the same in macOS 12.5.1, but doesn't work in either Windows 10 or 11.

Log File

vscode-debugadapter-e946278c.json.gz

VS Code Version: 1.70.2

Additional context
We are using this flag to be able to debug a node server that we spawn from our extension, this also applies to LSP, debug adapters that are implemented in node so that you are able to easily debug them.

[connor4312]

I tried to hit this by making the following change to the "hello world minimal sample"

diff --git a/helloworld-minimal-sample/.vscode/launch.json b/helloworld-minimal-sample/.vscode/launch.json
index 9a1bdb2..9043683 100644
--- a/helloworld-minimal-sample/.vscode/launch.json
+++ b/helloworld-minimal-sample/.vscode/launch.json
@@ -6,6 +6,7 @@
                        "type": "extensionHost",
                        "request": "launch",
                        "runtimeExecutable": "${execPath}",
+                       "autoAttachChildProcesses": true,
                        "args": ["--extensionDevelopmentPath=${workspaceFolder}"]
                }
        ]
diff --git a/helloworld-minimal-sample/extension.js b/helloworld-minimal-sample/extension.js
index 9b28fa2..57e0557 100644
--- a/helloworld-minimal-sample/extension.js
+++ b/helloworld-minimal-sample/extension.js
@@ -1,6 +1,7 @@
 // The module 'vscode' contains the VS Code extensibility API
 // Import the module and reference it with the alias vscode in your code below
 const vscode = require('vscode');
+const child_process = require('child_process');
 
 // this method is called when your extension is activated
 // your extension is activated the very first time the command is executed
@@ -18,6 +19,7 @@ function activate(context) {
        // The commandId parameter must match the command field in package.json
        let disposable = vscode.commands.registerCommand('extension.helloWorld', () => {
                // The code you place here will be executed every time your command is executed
+               child_process.spawnSync('node', ['-e', 'debugger;']);

                // Display a message box to the user
                vscode.window.showInformationMessage('Hello World!');

however, debugging worked and hitting the debugger; statement was successful. Are you able to upload a sample repo/zip where you're hitting this?

[segevfiner]

I'll try to create one once I have access to a PC where I'm sure this reproduces.

[segevfiner]

The thing is. This doesn't seem to happen on every computer. It happens on two at my workplace but not on my personal home computer.

https://github.com/segevfiner/vscode-issue-1374

[DivoK]

Managed to reproduce on my mac, log:
vscode-debugadapter-840c7f12.json.gz

{"tag":"runtime.target","timestamp":1669805742705,"message":"Error setting child environment vars","metadata":{"exceptionId":2,"text":"Uncaught","lineNumber":0,"columnNumber":14,"scriptId":"11","stackTrace":{"callFrames":[{"functionName":"","scriptId":"11","url":"eval-f654d951.cdp","lineNumber":0,"columnNumber":14}]},"exception":{"type":"object","subtype":"error","className":"ReferenceError","description":"ReferenceError: process is not defined\n    at eval-f654d951.cdp:1:15","objectId":"6358410330838730965.1.4"}},"level":3}

It seems like:

vscode-js-debug/src/targets/node/extensionHostAttacher.ts

Line 137 in c309425

private async setEnvironmentVariables(

Fails to set the environment variables with process is not defined. I'm not sure why this works on some computers but fails on others. The extension host seems to still be paused on the initial breakpoint at that point, so maybe it is executed too early before process is initialized due to some race condition on when the initial breakpoint fires?

cc @OmerRosenbaum @EinorZ

[connor4312]

We do retry several times to set it since I observed that error is hit when the debugger is first attaching. Maybe we need to increase the number of retries or the delay

vscode-js-debug/src/targets/node/extensionHostAttacher.ts

Lines 152 to 173 in c309425

	for (let retries = 0; retries < 5; retries++) {
	const result = await cdp.Runtime.evaluate({
	contextId: 1,
	returnByValue: true,
	expression:
	`Object.assign(process.env, ${JSON.stringify(vars.defined())})` + getSourceSuffix(),
	});
	if (!result) {
	this.logger.error(LogTag.RuntimeTarget, 'Undefined result setting child environment vars');
	} else if (result.exceptionDetails) {
	this.logger.error(
	LogTag.RuntimeTarget,
	'Error setting child environment vars',
	result.exceptionDetails,
	);
	} else {
	return;
	}
	await delay(50);
	}

[segevfiner]

I wonder if that will help cause when I debugged it, the error still happened even after delaying it more. It looked like the extension host remained frozen while this code runs, only continuing to initialize once it fails.

[connor4312]

The promise returned from that method is not awaited. However, you were paused there, you would may have been preventing the extension from later calling Runtime.runIfWaitingForDebugger which would keep the extension host frozen 🙂

[segevfiner]

So that's probably it, since the computers it was happening on were probably running a bit sluggish for one reason or another. At least enough to trigger this.

[connor4312]

We can probably be much, much more lenient about the retry loop. It doesn't really have any negative effect aside from negligible cpu use to send and receive the request. PR's welcome, otherwise I'll get to this in a little while...

[segevfiner]

I'll make a PR after testing that it really fixes the problem, although thinking about it, this still might race between the startup of the process and the spawning of the first child process, no?

[connor4312]

Indeed. But there's no a whole lot we can do about that, as far as I know.