You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Impossible to debug multi-threaded processes on headless server. #16469
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.
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.
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.
It's --inspect-port=0, note the = sign. --inspect-port 0 are two arguments and probably prints a warning or error.
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.
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
Activity
bnoordhuis commentedon Oct 25, 2017
Can you fill out the issue template? We ask it for a reason.
Follow inspector development in upstream Chromium. We're a downstream consumer.
conartist6 commentedon 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 commentedon Oct 26, 2017
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 commentedon 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 ./scriptdid 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 commentedon Oct 27, 2017
Couple of things:
It's
--inspect-port=0, note the=sign.--inspect-port 0are two arguments and probably prints a warning or error.Write
node --inspect-port=0 inspect ./script.js- the argument should go beforeinspect. Maybe you were thinking ofnode inspect --port=<port> ./script.js.I opened nodejs/node-inspect#51 to make binding to port zero work more smoothly.
conartist6 commentedon Oct 27, 2017
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:
vs
conartist6 commentedon Oct 27, 2017
Ah, but I see your diff fixes that, awesome!
fix: Make --inspect-port=0 work