Cannot use 'autoAttachChildProcesses' to debug forked processes

[perspectivus1]

• VSCode Version: 1.36.0-insider and 1.34.0
• OS Version: Windows 10 Enterprise
• Node Version: 10.16.0

The forked process launches and behaves as expected; however, the debugger does not pause on breakpoints of the forked code.

Hovering over the breakpoint shows Unverified breakpoint tooltip. In addition, the Debug activity bar shows Breakpoint set but not yet bound:

It occurs natively on Windows or in WSL using the Remote - WSL extention.

Steps to Reproduce:

1. Create 2 JavaScript files and 1 launch.json file as follows:

index.js

const child_process = require("child_process");
console.log(process.argv[0]);

process.execArgv.push('--debug=' + (40895));    
child_process.fork('./m1.js');

m1.js

console.log(`from fork: ${process.argv[0]}`);

launch.json

{
    "version": "0.2.0",
    "configurations": [
        {
            "type": "node",
            "request": "launch",
            "name": "run.vscode",
            "program": "${workspaceFolder}/index.js",
            "autoAttachChildProcesses": true
        }
    ]
}

2. Place breakpoints in both JavaScript files.
3. Debug the run.vscode launch configuration.

Does this issue occur when all extensions are disabled?: Yes

Is the autoAttachChildProcesses property supported for child_process.fork() or only for cluster.fork()?

[weinand]

autoAttachChildProcesses does not rely on any specific "fork".
But you are using the "--debug=" argument which is no longer supported for node.js versions > 8.x.
Please try "--inspect=" instead.

[perspectivus1]

I changed to --inspect=, and am observing the same behavior.

Are you saying I can skip forking with a debug port?

[weinand]

no, you will still have to put the child process in debug mode. Cluster.fork does this for you. If you are using the plain fork you'll have to do it yourself.

Since you are using --inspect instead of --inspect-brk you won't be able to hit breakpoints in early startup code because the debugger connects after the code has been executed.

I suggest to use --inspect-brk if your breakpoints are in early startup code.

[weinand]

In addition, be careful that you are not passing two --inspect... arguments to the child: if the main process is already launched with a --inspect... argument, fork passes it to the child too. If you add another --inspect... you end up with two. A better approach is to replace one debug port with another debug port in the execArgv array.

[perspectivus1]

So I got it to work by replacing these two lines:

process.execArgv.push('--debug=' + (40895));    
child_process.fork('./m1.js');

with:

child_process.fork('./m1.js', [], {execArgv:['--inspect-brk=40895']});

A couple of questions:

1. Is there a way not to specify the debug port for the forked process, in the same way I don't specify the debug port for the parent process?
2. If I must specify the debug port for the forked process, is there a way to determine an available port (or to ascertain the debug port of the parent process) in order to avoid port collisions?
3. I want to fork the child process in debug mode only if the parent process is being debugged. Can I determine in runtime whether the parent process is being debugged?
4. Is there detailed documentation about the autoAttachChildProcesses property? Specifically, I couldn't find an example of the execArgv trick you gave me in the docs.

Many thanks for your help!

[weinand]

1. forking children within a program is controlled by the user program, not by VS Code. So in general VS Code cannot know what the debug port will be.
2. use Cluster.fork
3. if process.execArgv contains an --inspect the parent is in debug mode.
4. the "execArgv trick" is independent from autoAttachChildProcesses. This is just common knowledge when forking node.js processes. Please see https://stackoverflow.com/questions/16840623/how-to-debug-node-js-child-forked-process