I have a command that looks basically like so:
node --inspect-brk=9229 a.js | node --inspect-brk=54031 b.js
When I start this command at the command line, I get this:
Debugger listening on ws://127.0.0.1:54031/66c60348-ce22-4acc-9ba3-aa97b8dd1f12
For help see https://nodejs.org/en/docs/inspector
Debugger listening on ws://127.0.0.1:9229/59c70b31-8af6-4c99-bdaf-c1a86f49d62b
For help see https://nodejs.org/en/docs/inspector
They are hardcoded to listen on different ports, one on the default (9229) the other on 54031.
However, when I debug with Chrome tools, only one Chrome debug window opens and when I try different urls, I cannot get a second debugging session to open.
The url that works is like so:
chrome-devtools://devtools/bundled/inspector.html?experiments=true&v8only=true&ws=localhost:9229/59c70b31-8af6-4c99-bdaf-c1a86f49d62b
and if I try pasting this into a new window:
chrome-devtools://devtools/bundled/inspector.html?experiments=true&v8only=true&ws://127.0.0.1:54031/66c60348-ce22-4acc-9ba3-aa97b8dd1f12
it doesn't work
Change
chrome-devtools://devtools/bundled/inspector.html?experiments=true&v8only=true&ws://127.0.0.1:54031/66c60348-ce22-4acc-9ba3-aa97b8dd1f12
to
chrome-devtools://devtools/bundled/inspector.html?experiments=true&v8only=true&ws=127.0.0.1:54031/66c60348-ce22-4acc-9ba3-aa97b8dd1f12
true&ws:// to true&ws=
I too tried this and its working just fine.
Related
To debug a Node.js process, I use:
node --inspect-brk foo_bar.js
But what if that instance would start another, separate instance, and this one would be - how to run that instance in debug mode as well?
The problem is, I am using the commander.js library for Node.js, like so:
var program = require('commander')
...
program.parse(process.argv)
This creates another instance of Node.js process, and hence I lose the debug functionality (I am debugging via Chromium browser). How can I overcome this?
Note: Commander only creates another process if you implement the subcommand using a stand-alone executable.
Commander detects debugger options being passed to the node invocation, and passes them to the subprocess with the debugging port incremented by 1.
e.g.
// index.js
const { program } = require('commander');
program
.command('sub', 'stand-alone');
console.log('1');
console.log('2');
program.parse();
// index-sub.js
console.log('3');
console.log('4');
% node --inspect-brk index.js sub
Debugger listening on ws://127.0.0.1:9229/25005682-6bf4-44fb-bdb2-2cc7749bb328
For help, see: https://nodejs.org/en/docs/inspector
Debugger attached.
1
2
Debugger listening on ws://127.0.0.1:9230/00d1924a-3122-4bef-86f2-65d562fbf3ed
For help, see: https://nodejs.org/en/docs/inspector
Debugger attached.
3
4
I have added the configuration in the launch.json file with the following details :
{
"name": "Attach"
"type": "node",
// TCP/IP address. Default is "localhost".
"address": "localhost",
// Port to attach to.
"port": 5858
}
Now I start my app with the following command : node --debug-brk ./bin/www
When i go to VSCode and select Attach in the debugging menu on the top and click on the play button.
It attaches, but when i go to browser and open a page, it doesn't it the breakpoint or the handler function in my index.js file.
Can you please help what could be going wrong?
There are two issues with breakpoints in node (and these issues are not specific to VSCode but you can see them in node-inspector as well):
If you set breakpoints in your app's startup code and launch node with --debug (opposed to --debug-brk), node starts immediately and has executed your startup code before VSCode had a chance to register the breakpoints. So if you need to debug startup code use the --debug-brk flag because it allows VSCode to set breakpoints before node starts the application.
Node does not parse source files completely on load but delays parsing of closures (callbacks etc.) until their code is first hit. As a consequence breakpoints set on callbacks are not always correctly registered by node, because it does not have parsed the code yet. This 'lazy' behaviour can be disabled by starting node with the --nolazy flag.
In the next version of VSCode (0.4.0) we try to address these problem as follows:
VScode will always launch node with the --debug-brk flag but will hide the first stop and continue if the user did not specify "stopOnEntry: true". This will avoid problems with missed breakpoints in startup code.
If breakpoints are set in code that has not been parsed by node, node will register them at the next possible position in parsed code. Since these "actual" positions are returned by node to the client, VSCode is able to show these positions. So the user will see that a breakpoint set in an unparsed callback "jumps" to a position further down and he will better understand why the debugger is not stopping at the location requested. In addition we added a "Reapply" button to the breakpoint view which makes it really easy to clear and set all breakpoints.
Your breakpoints are probably set too early and are not registered by node. It should help if you set the breakpoints after you have attached.
We have improved this experience in VSCode and it should be available in 0.4.0
Always clear your breakpoints and set them after you attach. I learned the hard way. This is certainly a bug.
I've been digging into this and here is what I have found so far for 0.3.0.
This does not work!
In Code add a breakpoint to app.js or a route
In terminal run node --debug src/server/app.js
In Code attach the debugger
This works!
In terminal run node --debug src/server/app.js
In Code remove all breakpoints
In Code add a breakpoint to app.js or a route
In Code attach the debugger
This does not work, as --debug doesn't kick in unless its the arg after node and before the file
In terminal run node src/server/app.js --debug
In Code remove all breakpoints
In Code add a breakpoint to app.js or a route
In Code attach the debugger
This works, assuming you have a gulp process
In terminal run gulp serve-dev --debug
In Code remove all breakpoints
In Code add a breakpoint to app.js or a route
In Code attach the debugger
This does not work, sometimes
In terminal run gulp serve-dev --debug
In Code add a breakpoint to app.js or a route
In Code attach the debugger
Why sometimes? The best I can tell is that that the breakpoints sometimes get funky. Sometimes they work fine, and other times I have to remove them and re-add them before attaching the debugger.
I run node server in console
Then in browser :8080/debug?port=5858
i see
My breakpoint doesnt work .
Help me please.
You need to run node-inspector after your app.
Also, in your case, it seems by the time you start inspector, the app will be past the section you want to debug. So try this:
# Console window 1
node --debug-brk run.js
# Console window 2
node-inspector
Then navigate to http://localhost:8080/debug?port=5858
The execution should be stopped on the first line of code. Set up your breakpoints and resume.
Im a little confused with all this nodejs debug syntax flying around.
I simply want to start the debugger on a process when I run it on a different port.
Normally I start debugging by node debug file.js
but now I have to process` running that I need to debug
Now I found the command node --debugger=7873 file.js but that starts the debugger and jumps past all the breaks and I tried node --debugger=7837 --debug-brk file.js but that forces me to consume another teminal window. How can I just run a script on a different port in the same terminal or with out using nohup?
node debug --port=[your port] your_program.js
responsible _debugger code here
I am trying to debug the child_process example from here using IntelliJ IDEA 12.1.3 and node 10.10. When I run nodejs app.js from a terminal everything works. The console output displays as expected. However, when I debug the same script using IDEA there are no messages in console output and the app just sits there. This is what is in the console window:
/usr/bin/nodejs --debug-brk=58954 app.js
debugger listening on port 58954
debugger listening on port 58954
When I run the script in IDEA without the debugger attached, the script works as expected.
Why does attaching the debugger break the script?
You can force the children to use a free port for debugging. InteliJ will automatically pick up the port chosen by the child process.
Here's an example:
// Determine if in debug mode.
// If so, pass in a debug-brk option manually, without specifying port.
var startOpts = {};
var isInDebugMode = typeof v8debug === 'object';
if(isInDebugMode) {
startOpts = {execArgv: ['--debug-brk']};
}
child_process.fork('./some_module.js', startArgs, startOpts);
looks like a bug in node.js fork to me: both parent and child processes receive --debug-brk=58954 switch and attempt to start debugger and listen port 58954.