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

Impossible to debug multi-threaded processes on headless server. #16469

Closed
conartist6 opened this issue Oct 25, 2017 · 7 comments
Closed

Impossible to debug multi-threaded processes on headless server. #16469

conartist6 opened this issue Oct 25, 2017 · 7 comments
Labels
inspector Issues and PRs related to the V8 inspector protocol

Comments

@conartist6
Copy link

conartist6 commented Oct 25, 2017

See closed issue #9435
and
#5025

While it is possible now to run node --inspect-brk=0, this only waits for a GUI to connect to the debugger. In my case a restrictive network configuration means that I can't actually connect a GUI debugger to a completely random port.

Thus my circumstances dictate that I need to use the CLI debugger with a random port. I would assume that the command to run would be

Expected: node inspect --inspect-port 0 launches the CLI debugger in the main thread, and the background thread does not crash with port 9229 in use errors.

Actual:

scripts/ads/interfaces/ice_routing/generate
< Debugger listening on ws://127.0.0.1:39163/7bc855ba-cd5e-4ad0-9c17-e3b04d94aae3
< For help see https://nodejs.org/en/docs/inspector
connecting to 127.0.0.1:9229 ............ failed to connect, please retry

In other news I'd love to know where we could track progress towards being able to debug multiple child processes over a single port.

@mscdex mscdex added the inspector Issues and PRs related to the V8 inspector protocol label Oct 25, 2017
@bnoordhuis
Copy link
Member

Can you fill out the issue template? We ask it for a reason.

In other news I'd love to know where we could track progress towards being able to debug multiple child processes over a single port.

Follow inspector development in upstream Chromium. We're a downstream consumer.

@conartist6
Copy link
Author

conartist6 commented Oct 25, 2017

v8.7.0,
Darwin cbuck-mbp 16.7.0 Darwin Kernel Version 16.7.0: Thu Jun 15 17:36:27 PDT 2017; root:xnu-3789.70.16~2/RELEASE_X86_64 x86_64

@bnoordhuis
Copy link
Member

Thanks. That MacBook probably isn't the machine you're having trouble with though, is it?

Can you post the exact steps you use to start node.js + connect to it? The snippet you posted seems to be a script executing. It hides the actual invocations.

@conartist6
Copy link
Author

conartist6 commented Oct 26, 2017

No, though I verified that I can cause the problem on my mac. It's not platform-specific. I forgot I posted the script. The actual invokation inside the script is the one I posted: `node inspect --inspect-port 0 ./script.js

Bizarrely just twice, in circumstances I don't really understand node inspect ./script did exactly what I wanted, which is not die of port in use errors and give me a debugger right there.

I also just figured out that it is possible to debug it. Node inspect can be used as a client when given a host and port combination, which works when I background the result of --inspect-brk=0.

Perhaps the easiest fix would be simply updating the documentation, but it would be nice if there was a way to run inspect and get the debugger on that process, without port conflicts, as I've suggested here.

@bnoordhuis
Copy link
Member

node inspect --inspect-port 0 ./script.js

Couple of things:

  1. It's --inspect-port=0, note the = sign. --inspect-port 0 are two arguments and probably prints a warning or error.

  2. Write node --inspect-port=0 inspect ./script.js - the argument should go before inspect. Maybe you were thinking of node inspect --port=<port> ./script.js.

I opened nodejs/node-inspect#51 to make binding to port zero work more smoothly.

@conartist6
Copy link
Author

You're right of course about =, that was a typo here.

I just tried putting the argument before inspect. You're quite correct that it does do something different than putting the argument after:

< Debugger listening on ws://127.0.0.1:44035/2b529c08-fc5d-467b-942f-1cd8e19c6a57
< For help see https://nodejs.org/en/docs/inspector
connecting to 127.0.0.1:0 ............ failed to connect, please retry

vs

< Debugger listening on ws://127.0.0.1:44081/fa5a4ce3-61e8-405b-a3ea-47c57a3f8fc9
< For help see https://nodejs.org/en/docs/inspector
connecting to 127.0.0.1:9229 ............ failed to connect, please retry

@conartist6
Copy link
Author

Ah, but I see your diff fixes that, awesome!

jkrems pushed a commit to nodejs/node-inspect that referenced this issue Jan 24, 2018
Selecting port zero makes the inspector bind to a random port.

The inspector prints the URL it listens on to stderr.  Parse the
output from the child process to find the port number.

This commit coincidentally also makes `node inspect --port=0 x.js`
work and a regression test to that effect has been added.

Note that connecting to an existing process that listens on a
non-standard port with `node inspect -p <pid>` does not work
because then we never see the output from the inspector.

Fixes: nodejs/node#16469
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
inspector Issues and PRs related to the V8 inspector protocol
Projects
None yet
Development

No branches or pull requests

3 participants