There have been a couple of older posts regarding this issue, but date from questions asked in 2013 and 2014 and the answers in there have not helped my case.
I have the debugger keyword placed in multiple places in my file, and have even added manual breakpoints in the inspector UI. Still, executing the file does not stop at any breakpoints. I am using node 9.2.0 and chrome 64.0.3282.167.
Here is a picture of how my devtools appears.
Use the --inspect-brk flag instead
I ended up opening up an issue on the devtools protocol github page.
I got an immediate answer. Basically, because I was using the --inspect flag to start the Node.js debugger, my JavaScript was being executed before the debugger process was connecting to the DevTools server. Therefore breakpoint information would be relayed too late and no breakpoints would be triggered.
Example: node --inspect-brk myscript.js
They're currently trying to improve this use case. Here's the actual reply:
We are working on better workflow here but for now --inspect-brk is
only one way. With --inspect-brk node waits DevTools frontend
connection. On connection DevTools send all breakpoints information
and starts JavaScript execution in node. With --inspect node starts
JavaScript execution without waiting for DevTools frontend. As soon as
DevTools connected, we send the same breakpoint information to node
but it can be too late since some JavaScript is already executed.
The Node.js docs are not very clear on this subtlety as of 4/6/2018. I will submit a PR on their repo to update the docs. BTW, if you are not aware, even without the V8 integration, the built-in debugger is very powerful. Explore all the possibilities of the debugging utility in the docs.
This is a problem that has been extremely annoying to me since 10.13 went to LTS and I upgraded from 8 to 10.
I was unable to find anything about this issue until I saw this question here on stack overflow, that was the catalyst I needed to be able find more about the problem and discover the cause and the solution.
You can find out more here: https://github.com/nodejs/node/issues/23693
The Why:
Basically it is because of a change to the debugger protocol in Node.
The Solution:
Upgrade Chrome to 71 or later which supports the change in the protocol.
Much Better Solution: Install NIM: https://chrome.google.com/webstore/detail/nodejs-v8-inspector-manag/gnhhdgbaldcilmgcpfddgdbkhjohddkj then go to the NIM settings and change the selected DevTools version to the one from chrome-devtools-frontend.appspot.com ( see more about this option here: https://june07.com/blog/nim-custom-devtools-url/ )
I have this issue too: Chrome Devtools Inspector not stopping at breakpoints.
My problematic software versions:
Chrome: Version 70.0.3538.77 (Official Build) (64-bit)
Node: v10.12.0
A workaround I found is to downgrade NodeJS to version 8.12.0 (the latest 8.x version). Node version 8.x works for me.
$ node -v
v8.12.0
I also tried Node version 10.13.0, 11.1.0, none of them works for me.
FYI: How to change Node version
The deeper reason seems to be that the debugger maintains two separate databases where it stores the breakpoints. Opening a file from the Sources tab, and setting breakpoints in it, is a waste of time. Maybe node considers these suspicious or unconfirmed -- whatever. They are ignored. These breakpoints are stored "somewhere" but not in the place that an active debugging session finds them or respects them.
You need to first manage to break the active execution of the source file that you want to debug, and then set the breakpoints while in a running context. You will notice that all breakpoints that you had previously set via the Sources tab have disappeared, and you can set new breakpoints. Only those new breakpoints are "observed" by node at runtime.
So the workaround today (September 2019) is as follows:
Pepper the source file you wish to debug with debugger; statements
Start your project with inspect-brk to force the debugger to stop the program before its first line is executed
Click the little blue arrow to continue execution normally; the debugger; statements should now break in the source file you are interested in.
Once you are stopped, you can set breakpoints that will actually be observed, and saved, in the "correct database" (for the lack of a better term).
I had the same issue today while working with 10.13.0. based on the comment from answer 4, I tested different versions with $ nodenv local <version> and I had the following results:
10.13.0 (not working)
10.12.0 (not working)
10.11.0 (working)
10.10.0 (working)
Assuming lower versions work.
If you're not familiar with nodenv, you can get it here https://github.com/nodenv/nodenv
I found that if I manually type:
debugger;
where I want the breakpoint to occur in my code then this actually fixes this issue for me.
e.g.
var counter=0;
while (true) {
for (i = 0; i < 5; i++) {
debugger; //enter this through Chrome Dev then press CTRL s to save
counter++;
}
}
I'm running the above via:
node --inspect-brk=0.0.0.0:5000 test_debugger.js
[The 0.0.0.0 is here due to this being on a remote server.]
I had a similar problem and found an easy fix. Instead of using chrome devtools, try node-inspector, which does the same thing - https://github.com/node-inspector/node-inspector#quick-start
Open node.js command prompt
Install the node-inspector package npm install -g node-inspector
node-debug <your-entry-point> replace <your-entry-point> with your 'main' file, usually app.js by default (remember to navigate to the full file location if not already there e.g. C:\Users..)
Wait for new browser window with node-inspector to open
Related
still new to Electron/Node and am trying to debug an issue I'm experiencing with the msnodesqlv8 package. In the file that throws errors (bootstrap.js) there are several console.log(...) calls that do not appear in the DevTools console or in the command prompt where electron was called either, like those that are called in the renderer process. Is there anything that I can do to see where this is being logged?
This code is an out of the box installation of the Electron React Boilerplate with nothing changed besides the installation of the msnodesqlv8 package and one line added to index.js to require it.
I have attempted to connect a separate DevTools instance to the main process debugger through electron's --inspect flag per Electron and Node guides, but they are incomplete/outdated and I cannot form the necessary connection -- or at least do not know where to find the complete information.
Sorry for the beginner question but I am a bit lost here.
Is is possible to debug a wasm module through node?
I am using vscode and compiling with emcc -g4 --source-map-base. Putting a breakpoint in the C source file is ineffective. Trying to debug with node inspector node --inspect through Chrome doesn't allow me to use breakpoints either, although it is possible to debug wasm modules from regular web pages in Chrome.
I am using nodejs v10.13.
WebAssembly Source Maps is supported by both Firefox Developer Edition (in screenshot) and Chrome 71.
What you forgot is, to include a path to the source map. For example:
emcc -g4 --source-map-base http://localhost:8000/
Every source files path is prefixed with http://localhost:8000/ with this option. So replace this with your source directory.
So, I managed to get something working. I installed:
Node v11.4
Chrome beta 71 (because of this)
And launched the node process with node --inspect, for attaching the Chrome DevTools.
Moreover, in my code, instead of doing WebAssembly.instantiate in one shot (supplying directly the bitcode), I do it in two steps: WebAssembly.compile first, and then WebAssembly.instantiate. As soon as compile gets executed, there are some "wasm" sources being made available in the DevTools. This is the WebAssembly in wast text form, in which breakpoints can be set before it gets executed by instantiate.
But you can't debug from the original C-source files, Chrome DevTools only shows the decompiled wast yet. This feels like the stone age of debugging, but it is still possible to debug.
Edit 2020: This article https://developers.google.com/web/updates/2019/12/webassembly seems to indicate you should now be able to debug in devtools, from the original C source files. I did not try it, though.
I have a Node app that basically does some work and exits. This happens really fast, maybe in a second, so when I do
node --inspect app.js
I don't have enough time to open Chrome and set the breakpoint in order to stop the script.
Is there some other way to debug the script, e.g. somehow pre-set the breakpoint or make it stop immediately on the first line?
Have you had a look at the NodeJs debugger?
Node Debug
To use it, start Node.js with the inspect argument followed by the path to the script to debug.
eg.
$ node inspect myscript.js
Have a look at the breakpoint section in particular:-
Node Debugger Breakpoints
You can include:-
setBreakpoint(line)
to set breakpoints on specific lines.
You can find all the popular node.js debugging apps available in the link below :
https://nodejs.org/en/docs/inspector/
Using node-inspect, you can set a breakpoint on current line or specific line using :
setBreakPoint()
There are many other options of setBreakpoint() depending on your requirement which you can find in the documentation Here
Alternatively, I'd suggest using VSCode which has inbuilt debugger with which you can place a breakpoint in the editor itself. You can debug your node.js app in your IDE instead of opening a chrome web inspector or putting debug logs in the code and it is very simple to configure the app. Just create a launch configuration based on how you launch your node.js app and run it.
Node.js debugging with VSCode is clearly explained in their docs Here
You can do the same with WebStorm too but you need a paid license to use the WebStorm compared to VSCode which OpenSource.
Try to use the following
node --inspect-brk app.js
it will start the process with an active breakpoint at the very beginning of the program.
I have a web application that is written in node.js and gets started using a gulp command. When the application first starts, before the server is running, debug points may be hit in WebStorm (or in any IDE or command line tool). However, after the server is running and I go to the interface in my localhost I can no longer hit debug points inside the application. This is not being caused by client side code as the debug points are in server code.
I have read the answers that involve using the node-inspector and that has not solved my problem because of configuration files that are not getting read when starting the debugger in node inspector.
I'm a bit surprised that there is so little on here about this issue. Is it not a normal problem that other developers face? Thanks in advance for the help.
My workaround for this may not be sufficient for every case. I was modifying JavaScript files and didn't actually need the configuration files, after loading, to be able to test my changes. I did the following:
Wrote a line in my app.js file that set the variables I needed. (these would have been tasks ran in Gulp)
I then started the app as a Node.js app and was able to debug it as normal.
If any of my views had been updated, or anything else that was being managed by Gulp, then I could have simply stopped the server, started it again via the Gulp command, and then stopped again and restarted as a Node.js app.
This did not solve the issue in my OP but it was a good enough workaround to get debug points in the JavaScript.
I have been seeking solutions for debugging Node.js based web application from days. I had tried to debug with Eclipse + Chrome debugger plugin but failed, I posted the error in this session 'Failed to get tabs for debugging' when trying to debug NodeJs with chrome debugger for Eclipse, but could not find an answer.
However, as Node.js is so popular, I have no doubt that a lot developers have the solution for debugging Node.js server JavaScript code. I appretiate if you could share me your solution of setting up an IDE (edit and debug) for Node.js server JavaScript code, or at least how to debug it.
I would suggest using node-inspector. Here is a good tutorial for setting it up. It allows you to use a browser tab to look at your code, set breakpoints, and step through it. Additionally, you can start node with the flag --debug-brk and it will insert a break point on the first line, if you need to debug something that happens on startup.
There are several tools to debug a node application. A great ressource has been postet on Github recently.
A simple debugging setup might be just adding a breakpoint to your code and start node in debug mode like this:
Example code with use of debugger, a manual breakpoint.
app.get('/foo', function(req, res) {
var something = 123;
debugger; // execution stops if this point is reached
foo(something);
});
Start node in debug mode:
$ node debug app.js
Once you started the application in debug mode you use the application (e.g., navigate to the ressource with your browser) and once a breakpoint occurs, the execution stops and you have a debugger environment in your terminal.
Try to use Weinre (WEb INspector REmote). It's a node app help you debug UI, log for web app on devices.
It hope it can help you.