Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Node process with --inspect cannot fork child process without passing --inspect #14325

Closed
unbornchikken opened this issue Jul 17, 2017 · 10 comments
Labels
child_process Issues and PRs related to the child_process subsystem. inspector Issues and PRs related to the V8 inspector protocol windows Issues and PRs related to the Windows platform.

Comments

@unbornchikken
Copy link

unbornchikken commented Jul 17, 2017

  • Version: 8.1.1
  • Platform: Windows 10

If I start a node process with --inspect and fork a child node process without passing --inspect, child process will crash with exit code of 12.

Is this the intended behavior?

Edit: added a repro case there #14325 (comment)

@Trott Trott added the inspector Issues and PRs related to the V8 inspector protocol label Jul 17, 2017
@mscdex mscdex added child_process Issues and PRs related to the child_process subsystem. windows Issues and PRs related to the Windows platform. labels Jul 17, 2017
@bnoordhuis
Copy link
Member

Test case? I think I know what you mean but I'd rather not guess and guess wrong.

@eugeneo
Copy link
Contributor

eugeneo commented Jul 17, 2017

This is caused by the default inspector port being taken up by the inspector. I can see exactly same behavior when running Node 6.11 with --debug. This issue can be avoided by running Node with port 0 (--inspect=0).

Should there be some special handling for --inspect?

@gibfahn
Copy link
Member

gibfahn commented Jul 18, 2017

If the --inspect isn't passed to the forked process, how is the inspector enabled for it?

@unbornchikken
Copy link
Author

@bnoordhuis Yeah, sorry about that rushed report, I'm trying to make a small repro case asap. @eugeneo That was my first suspect, but @gibfahn is right, the actual case is that --inspect isnot passed to the child, while the parent got started with --inspect passed. Being explicit with the port number in the argument doesn't help though, the child will crash.

@gibfahn
Copy link
Member

gibfahn commented Jul 18, 2017

Being explicit with the port number in the argument doesn't help though, the child will crash.

What @eugeneo is saying is that if you pass 0, then node will pick a free port, so the forked process will pick a different port and not conflict with the parent. Have you tried passing 0?

Still not sure why the inspector is enabled for the forked process.

@unbornchikken
Copy link
Author

unbornchikken commented Jul 18, 2017

Here is the repro script: https://gist.github.com/unbornchikken/298b6c507cea82a81074b801271f15d6

node repro

will run fine, however

node --inspect repro

will result with:

$ node --inspect repro.js
Debugger listening on ws://127.0.0.1:9229/cea75bbb-107e-470e-882d-644d46241e43
For help see https://nodejs.org/en/docs/inspector
Parent started.
Starting inspector on 127.0.0.1:9229 failed: address already in use
Forked child exit, code: 12
Forked child close.

It seems fork secretly pass an --inspect argument, but I don't belive that is an expected behavior, because it will never work this way, because parent is always holding the default inspect port in this case.

Being explicit with the inspect port will result:

$ node --inspect=55555 repro.js
Debugger listening on ws://127.0.0.1:55555/ed7f4b59-67f7-4737-86db-16aacf4f5546
For help see https://nodejs.org/en/docs/inspector
Parent started.
Starting inspector on 127.0.0.1:55555 failed: address already in use
Forked child exit, code: 12
Forked child close.

Again, the inspect argument got passed as is. But it should never work that way, because parent has been holding this for sure.

@bnoordhuis
Copy link
Member

There's no secret: child_process.fork() accepts a .execArgv option that defaults to process.execArgv when omitted.

@unbornchikken
Copy link
Author

@bnoordhuis The problem is that I had no issue of this kind with Node.js 4 --debug. The situation is that I've upgraded to Node 8 from version 4 and I can see that many of my unit tests started to get failed when I try to debug 'em. The interesting part is that you are of course right about that execArgv propagation. If I nvm back to node 4 and use --debug instead of --inpect I get address-already-use error on the side of child. I'm still investigating the cause of this, but I'm gonna close this issue.

@medikoo
Copy link

medikoo commented Jul 18, 2017

Seems related to #9435

@refack
Copy link
Contributor

refack commented Aug 16, 2017

If I nvm back to node 4 and use --debug instead of --inspect I get address-already-use error on the side of child. I'm still investigating the cause of this, but I'm gonna close this issue.

The main reason is that --debug and --inspect are completely different implementation, not just the debugger protocol, but also the listening server. It's not surprising that they have different peculiarities.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
child_process Issues and PRs related to the child_process subsystem. inspector Issues and PRs related to the V8 inspector protocol windows Issues and PRs related to the Windows platform.
Projects
None yet
Development

No branches or pull requests

8 participants