VS Code server spams CPU when a connection on its --socket-path is closed

[connor4312]

Using the CLI I notice sometimes there are rogue VS Code server processes that are at 100% CPU. Attaching to these processes, I see infinite logs for this error:

and a profile shows that's exactly what it's doing (left heavy view)

I want to improve some of the process handling in the CLI, but the VS Code server should also probably not do this. I also suspect this could be hit in normal usage if it's triggered just by a connection on the socket path closing.

[alexdima]

@connor4312 I would love repro steps! . I don't think this is about the --socket-path getting closed, but maybe about stdout getting broken.

I've seen this before in microsoft/vscode-remote-release#6543 but we lost the repro because the extension changed something in the way the server is spawned.

At the time, I remember we tracked it down to a change in nodejs 16, which does something better with stream errors, and which results now in async errors being produced if the console is trying to write to a broken stream.

And we have an unhandled error handler ... which tries to log to the console.

[alexdima]

Here's the kind of code I tried which didn't repro:

const path = require('path');
const fs = require('fs');
const child_process = require('child_process');

const output = path.join(__dirname, 'out.txt');
const outStream = fs.createWriteStream(output);

outStream.on('open', () => {
	const server_process = child_process.spawn(
		'/Users/alex/src/vscode/.build/node/v16.14.2/darwin-arm64/node',
		['/Users/alex/src/vscode/out/server-main.js'],
		{
			stdio: ['pipe', outStream, 'pipe'],
		}
	);

	console.log(`SPAWNED SERVER PROCESS AT ${server_process.pid}`);

	setTimeout(() => {
		console.log(`CLOSING STDOUT STREAM`);
		outStream.close();
	}, 1000);
});

[connor4312]

I'll see what I can do to get better steps

[vscodenpa]

This issue has been closed automatically because it needs more information and has not had recent activity. See also our issue reporting guidelines.

Happy Coding!

[connor4312]

Version: 1.74.0-insider (user setup) Commit: d9a70c4 Date: 2022-11-17T05:26:03.777Z Electron: 19.1.3 Chromium: 102.0.5005.167 Node.js: 16.14.2 V8: 10.2.154.15-electron.0 OS: Windows_NT x64 10.0.19045 Sandboxed: Yes

• In VS Code Desktop on machine A, start a tunnel with the `Enable Remote Tunnel Access' command
• on machine B use the 'Remote Tunnel' extension and use the Connect to Tunnel... command
• close and reopen VS Code on machine A (e.g. caused by an VS Code update). The tunnel is stopped and restarted
• The remote window on machine B gets stale, then says reconnecting, but doesn't succeed.
• Close the remote window, and use Connect to Tunnel... again. Machine A shows up in the list, but connecting to it doesn't succeed, connection goes on forever.
• Progress says:

Connecting to Nelson-win10-bootcam: Found running server (pid=3192)

Log says:

The log on machine A shows

2022-11-17 14:13:06.314 [info] [2022-11-17 14:13:06] info [tunnels::connections::relay_tunnel_host] Opened new client on channel 2

2022-11-17 14:13:07.263 [info] [2022-11-17 14:13:07] info [rpc.0] Checking C:\Users\martinae/.vscode-cli\server-insiders\.d9a70c4236a8bde4fe7435df3ecdd333c7bc939c.log and C:\Users\martinae/.vscode-cli\server-insiders\.d9a70c4236a8bde4fe7435df3ecdd333c7bc939c.pid for a running server...

2022-11-17 14:13:07.546 [info] [2022-11-17 14:13:07] info [rpc.0] Found running server (pid=3192)

from @aeschli in the private repo. And I believe this is the same issue that @chrisdias reported in #general.

I believe this is the same cause. I don't always get the CPU spam, but when I do, it results in the broken state. Consistent dev steps for me:

1. Run with cargo build && ./target/debug/code tunnel --verbose. This is necessary, since cargo run automatically cleans up the process tree (cargo run kills child processes upon exit rust-lang/cargo#5598). Finding that was fun 😆 Alternatively, just run the released VS Code CLI.
2. Connect on that tunnel
3. pkill -9 -f tunnel to force kill the CLI
4. Start the CLI again
5. Try to connect again, then you get CPU spam and the connection never goes through.

This makes sense with the original stacktrace, since stdout/stderr for the child process would then be closed.

[connor4312]

Oh, this is actually the same as microsoft/vscode-remote-release#6543