Provide `stdout` and `stderr` from utility process and adopt in extension host

[alexdima]

• configure "extensions.experimental.useUtilityProcess": true
• run `Developer: Show Running Extensions”
• press the black circle icon in the editor title
• this should enable inspecting the extension host and start profiling
• this requires a restart because this method for UtilityProcess extension hosts is not working similarly to this method for regular nodejs extension host

[deepak1556]

Update:

I was able to confirm that SIGUSR1 signal handlers are installed by Node.js inside the utility process via https://github.com/nodejs/node/blob/main/src/inspector_agent.cc#L92-L138

Also, process._debugProcess() action is indeed invoked via https://github.com/microsoft/vscode/blob/main/src/vs/platform/extensions/electron-main/extensionHostStarter.ts#L371-L392, to confirm

• Make the following when running out of sources so that inspector does not get started on startup

diff --git a/src/vs/platform/environment/common/environmentService.ts b/src/vs/platform/environment/common/environmentService.ts
index d90cbc60fef..32ff30de6da 100644
--- a/src/vs/platform/environment/common/environmentService.ts
+++ b/src/vs/platform/environment/common/environmentService.ts
@@ -270,7 +270,7 @@ export function parsePtyHostPort(args: NativeParsedArgs, isBuild: boolean): IDeb
 
 function parseDebugParams(debugArg: string | undefined, debugBrkArg: string | undefined, defaultBuildPort: number, isBuild: boolean, debugId?: string, environmentString?: string): IExtensionHostDebugParams {
        const portStr = debugBrkArg || debugArg;
-       const port = Number(portStr) || (!isBuild ? defaultBuildPort : null);
+       const port = Number(portStr) || null;
        const brk = port ? Boolean(!!debugBrkArg) : false;
        let env: Record<string, string> | undefined;
        if (environmentString) {

• .\scripts\code.sh
• Developer: Show running extensions and click profile action
• Now see main process console output which will now print

Debugger listening on ws://127.0.0.1:61222/fa9f6ced-bf9b-49a1-ba32-30690c6ccbfc
For help, see: https://nodejs.org/en/docs/inspector

The problem is that we try to obtain the inspector port for the above action from the stdout/stderr of the extension host process in

vscode/src/vs/workbench/services/extensions/electron-sandbox/localProcessExtensionHost.ts

Lines 292 to 295 in ef65ac1

	if (!this._inspectPort) {
	this._inspectPort = Number(inspectorUrlMatch[2]);
	this._onDidSetInspectPort.fire();
	}

Since we current don't support stdout and stderr events for the utility process, we end up with empty inspector ports even though the inspector is started leading to failed profile action which ends up triggering the fallback. Maybe a temporary fix would be to read from the main process stdout. I will see if UtilityProcess.stdout, UtilityProcess.stderr can be implemented to make life easier.

[bpasero]

I will see if UtilityProcess.stdout, UtilityProcess.stderr can be implemented to make life easier.

👍 . I had a brief look and it seems we listen to output and stderr not only for the purpose of obtaining the inspect port, but also to observe output and print it in general:

vscode/src/vs/workbench/services/extensions/electron-sandbox/localProcessExtensionHost.ts

Lines 271 to 276 in eebdf81

	const onStdout = this._handleProcessOutputStream(this._extensionHostProcess.onStdout);
	const onStderr = this._handleProcessOutputStream(this._extensionHostProcess.onStderr);
	const onOutput = Event.any(
	Event.map(onStdout.event, o => ({ data: `%c${o}`, format: [''] })),
	Event.map(onStderr.event, o => ({ data: `%c${o}`, format: ['color: red'] }))
	);

So I think we need this anyway, not just for debugging purposes. I wonder if this could also impact extension developers that want to log messages...