Chrome Devtools Dedicated Node.js Inspector not stopping at breakpoints
up vote
3
down vote
favorite
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.
node.js google-chrome-devtools
add a comment |
up vote
3
down vote
favorite
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.
node.js google-chrome-devtools
add a comment |
up vote
3
down vote
favorite
up vote
3
down vote
favorite
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.
node.js google-chrome-devtools
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.
node.js google-chrome-devtools
node.js google-chrome-devtools
asked Feb 26 at 18:29
Govind Rai
3,95412645
3,95412645
add a comment |
add a comment |
6 Answers
6
active
oldest
votes
up vote
4
down vote
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
1
Thanks for workaround! I spend couple of hours figuring where is the problem. Actually found that the latest working version is 10.11.0.
– Vitaljok
Nov 9 at 8:42
add a comment |
up vote
2
down vote
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
add a comment |
up vote
2
down vote
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/ )
add a comment |
up vote
1
down vote
accepted
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.
1
Tried this but it's not working for me. I was using just--inspect
before and only injectingdebugger;
into my code could I hit a breakpoint. Changing to--inspect-brk
didn't fix it.
– stuffyjoelab
Jun 22 at 3:32
I'm now experiencing failure of the --inspect-brk flag to pause execution, when previously it worked. I'm running node.js V8.11.3 LTS, and Chrome reports its version as follows: 68.0.3440.106 (Official Build) (64-bit) Execution of node scripts fails to halt on "debugger" statements AND manually set breakpoints.
– David Edwards
Aug 15 at 16:19
This is not the correct answer.--inspect-brk
will successfully pause the application at the application entry point, but does not solve the issue with breakpoints set elsewhere in the code via the GUI.
– WoodyWoodsta
Nov 13 at 11:18
@WoodyWoodsta at the time I asked this question, node was not having issues with some versions not working correctly with the debugging client. This was a very recent issue and this question (which was asked in april) got bombarded in november. But the answer still holds. It seems like the node debugging issues are fixed as of now. This answer still provides the key information on debugging node apps using the chrome inspector, which is to use theinspect-brk
flag to ensure none of your break points are missed.
– Govind Rai
Dec 8 at 20:20
@GovindRai Apologies. It appears the node debugger is rather... buggy at the moment :)
– WoodyWoodsta
Dec 9 at 21:04
add a comment |
up vote
0
down vote
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
add a comment |
up vote
0
down vote
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.]
add a comment |
Your Answer
StackExchange.ifUsing("editor", function ()
StackExchange.using("externalEditor", function ()
StackExchange.using("snippets", function ()
StackExchange.snippets.init();
);
);
, "code-snippets");
StackExchange.ready(function()
var channelOptions =
tags: "".split(" "),
id: "1"
;
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function()
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled)
StackExchange.using("snippets", function()
createEditor();
);
else
createEditor();
);
function createEditor()
StackExchange.prepareEditor(
heartbeatType: 'answer',
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader:
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
,
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
);
);
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f48994836%2fchrome-devtools-dedicated-node-js-inspector-not-stopping-at-breakpoints%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
6 Answers
6
active
oldest
votes
6 Answers
6
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
4
down vote
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
1
Thanks for workaround! I spend couple of hours figuring where is the problem. Actually found that the latest working version is 10.11.0.
– Vitaljok
Nov 9 at 8:42
add a comment |
up vote
4
down vote
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
1
Thanks for workaround! I spend couple of hours figuring where is the problem. Actually found that the latest working version is 10.11.0.
– Vitaljok
Nov 9 at 8:42
add a comment |
up vote
4
down vote
up vote
4
down vote
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
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
edited Nov 8 at 15:35
answered Nov 8 at 15:26
Yuci
3,7312734
3,7312734
1
Thanks for workaround! I spend couple of hours figuring where is the problem. Actually found that the latest working version is 10.11.0.
– Vitaljok
Nov 9 at 8:42
add a comment |
1
Thanks for workaround! I spend couple of hours figuring where is the problem. Actually found that the latest working version is 10.11.0.
– Vitaljok
Nov 9 at 8:42
1
1
Thanks for workaround! I spend couple of hours figuring where is the problem. Actually found that the latest working version is 10.11.0.
– Vitaljok
Nov 9 at 8:42
Thanks for workaround! I spend couple of hours figuring where is the problem. Actually found that the latest working version is 10.11.0.
– Vitaljok
Nov 9 at 8:42
add a comment |
up vote
2
down vote
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
add a comment |
up vote
2
down vote
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
add a comment |
up vote
2
down vote
up vote
2
down vote
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 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
answered Nov 12 at 0:57
egaxhaj
311
311
add a comment |
add a comment |
up vote
2
down vote
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/ )
add a comment |
up vote
2
down vote
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/ )
add a comment |
up vote
2
down vote
up vote
2
down vote
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/ )
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/ )
edited Nov 13 at 21:21
answered Nov 13 at 19:59
Dan Willett
1451211
1451211
add a comment |
add a comment |
up vote
1
down vote
accepted
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.
1
Tried this but it's not working for me. I was using just--inspect
before and only injectingdebugger;
into my code could I hit a breakpoint. Changing to--inspect-brk
didn't fix it.
– stuffyjoelab
Jun 22 at 3:32
I'm now experiencing failure of the --inspect-brk flag to pause execution, when previously it worked. I'm running node.js V8.11.3 LTS, and Chrome reports its version as follows: 68.0.3440.106 (Official Build) (64-bit) Execution of node scripts fails to halt on "debugger" statements AND manually set breakpoints.
– David Edwards
Aug 15 at 16:19
This is not the correct answer.--inspect-brk
will successfully pause the application at the application entry point, but does not solve the issue with breakpoints set elsewhere in the code via the GUI.
– WoodyWoodsta
Nov 13 at 11:18
@WoodyWoodsta at the time I asked this question, node was not having issues with some versions not working correctly with the debugging client. This was a very recent issue and this question (which was asked in april) got bombarded in november. But the answer still holds. It seems like the node debugging issues are fixed as of now. This answer still provides the key information on debugging node apps using the chrome inspector, which is to use theinspect-brk
flag to ensure none of your break points are missed.
– Govind Rai
Dec 8 at 20:20
@GovindRai Apologies. It appears the node debugger is rather... buggy at the moment :)
– WoodyWoodsta
Dec 9 at 21:04
add a comment |
up vote
1
down vote
accepted
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.
1
Tried this but it's not working for me. I was using just--inspect
before and only injectingdebugger;
into my code could I hit a breakpoint. Changing to--inspect-brk
didn't fix it.
– stuffyjoelab
Jun 22 at 3:32
I'm now experiencing failure of the --inspect-brk flag to pause execution, when previously it worked. I'm running node.js V8.11.3 LTS, and Chrome reports its version as follows: 68.0.3440.106 (Official Build) (64-bit) Execution of node scripts fails to halt on "debugger" statements AND manually set breakpoints.
– David Edwards
Aug 15 at 16:19
This is not the correct answer.--inspect-brk
will successfully pause the application at the application entry point, but does not solve the issue with breakpoints set elsewhere in the code via the GUI.
– WoodyWoodsta
Nov 13 at 11:18
@WoodyWoodsta at the time I asked this question, node was not having issues with some versions not working correctly with the debugging client. This was a very recent issue and this question (which was asked in april) got bombarded in november. But the answer still holds. It seems like the node debugging issues are fixed as of now. This answer still provides the key information on debugging node apps using the chrome inspector, which is to use theinspect-brk
flag to ensure none of your break points are missed.
– Govind Rai
Dec 8 at 20:20
@GovindRai Apologies. It appears the node debugger is rather... buggy at the moment :)
– WoodyWoodsta
Dec 9 at 21:04
add a comment |
up vote
1
down vote
accepted
up vote
1
down vote
accepted
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.
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.
answered Apr 6 at 18:51
Govind Rai
3,95412645
3,95412645
1
Tried this but it's not working for me. I was using just--inspect
before and only injectingdebugger;
into my code could I hit a breakpoint. Changing to--inspect-brk
didn't fix it.
– stuffyjoelab
Jun 22 at 3:32
I'm now experiencing failure of the --inspect-brk flag to pause execution, when previously it worked. I'm running node.js V8.11.3 LTS, and Chrome reports its version as follows: 68.0.3440.106 (Official Build) (64-bit) Execution of node scripts fails to halt on "debugger" statements AND manually set breakpoints.
– David Edwards
Aug 15 at 16:19
This is not the correct answer.--inspect-brk
will successfully pause the application at the application entry point, but does not solve the issue with breakpoints set elsewhere in the code via the GUI.
– WoodyWoodsta
Nov 13 at 11:18
@WoodyWoodsta at the time I asked this question, node was not having issues with some versions not working correctly with the debugging client. This was a very recent issue and this question (which was asked in april) got bombarded in november. But the answer still holds. It seems like the node debugging issues are fixed as of now. This answer still provides the key information on debugging node apps using the chrome inspector, which is to use theinspect-brk
flag to ensure none of your break points are missed.
– Govind Rai
Dec 8 at 20:20
@GovindRai Apologies. It appears the node debugger is rather... buggy at the moment :)
– WoodyWoodsta
Dec 9 at 21:04
add a comment |
1
Tried this but it's not working for me. I was using just--inspect
before and only injectingdebugger;
into my code could I hit a breakpoint. Changing to--inspect-brk
didn't fix it.
– stuffyjoelab
Jun 22 at 3:32
I'm now experiencing failure of the --inspect-brk flag to pause execution, when previously it worked. I'm running node.js V8.11.3 LTS, and Chrome reports its version as follows: 68.0.3440.106 (Official Build) (64-bit) Execution of node scripts fails to halt on "debugger" statements AND manually set breakpoints.
– David Edwards
Aug 15 at 16:19
This is not the correct answer.--inspect-brk
will successfully pause the application at the application entry point, but does not solve the issue with breakpoints set elsewhere in the code via the GUI.
– WoodyWoodsta
Nov 13 at 11:18
@WoodyWoodsta at the time I asked this question, node was not having issues with some versions not working correctly with the debugging client. This was a very recent issue and this question (which was asked in april) got bombarded in november. But the answer still holds. It seems like the node debugging issues are fixed as of now. This answer still provides the key information on debugging node apps using the chrome inspector, which is to use theinspect-brk
flag to ensure none of your break points are missed.
– Govind Rai
Dec 8 at 20:20
@GovindRai Apologies. It appears the node debugger is rather... buggy at the moment :)
– WoodyWoodsta
Dec 9 at 21:04
1
1
Tried this but it's not working for me. I was using just
--inspect
before and only injecting debugger;
into my code could I hit a breakpoint. Changing to --inspect-brk
didn't fix it.– stuffyjoelab
Jun 22 at 3:32
Tried this but it's not working for me. I was using just
--inspect
before and only injecting debugger;
into my code could I hit a breakpoint. Changing to --inspect-brk
didn't fix it.– stuffyjoelab
Jun 22 at 3:32
I'm now experiencing failure of the --inspect-brk flag to pause execution, when previously it worked. I'm running node.js V8.11.3 LTS, and Chrome reports its version as follows: 68.0.3440.106 (Official Build) (64-bit) Execution of node scripts fails to halt on "debugger" statements AND manually set breakpoints.
– David Edwards
Aug 15 at 16:19
I'm now experiencing failure of the --inspect-brk flag to pause execution, when previously it worked. I'm running node.js V8.11.3 LTS, and Chrome reports its version as follows: 68.0.3440.106 (Official Build) (64-bit) Execution of node scripts fails to halt on "debugger" statements AND manually set breakpoints.
– David Edwards
Aug 15 at 16:19
This is not the correct answer.
--inspect-brk
will successfully pause the application at the application entry point, but does not solve the issue with breakpoints set elsewhere in the code via the GUI.– WoodyWoodsta
Nov 13 at 11:18
This is not the correct answer.
--inspect-brk
will successfully pause the application at the application entry point, but does not solve the issue with breakpoints set elsewhere in the code via the GUI.– WoodyWoodsta
Nov 13 at 11:18
@WoodyWoodsta at the time I asked this question, node was not having issues with some versions not working correctly with the debugging client. This was a very recent issue and this question (which was asked in april) got bombarded in november. But the answer still holds. It seems like the node debugging issues are fixed as of now. This answer still provides the key information on debugging node apps using the chrome inspector, which is to use the
inspect-brk
flag to ensure none of your break points are missed.– Govind Rai
Dec 8 at 20:20
@WoodyWoodsta at the time I asked this question, node was not having issues with some versions not working correctly with the debugging client. This was a very recent issue and this question (which was asked in april) got bombarded in november. But the answer still holds. It seems like the node debugging issues are fixed as of now. This answer still provides the key information on debugging node apps using the chrome inspector, which is to use the
inspect-brk
flag to ensure none of your break points are missed.– Govind Rai
Dec 8 at 20:20
@GovindRai Apologies. It appears the node debugger is rather... buggy at the moment :)
– WoodyWoodsta
Dec 9 at 21:04
@GovindRai Apologies. It appears the node debugger is rather... buggy at the moment :)
– WoodyWoodsta
Dec 9 at 21:04
add a comment |
up vote
0
down vote
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
add a comment |
up vote
0
down vote
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
add a comment |
up vote
0
down vote
up vote
0
down vote
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
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
answered Apr 5 at 15:03
sharaz
1
1
add a comment |
add a comment |
up vote
0
down vote
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.]
add a comment |
up vote
0
down vote
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.]
add a comment |
up vote
0
down vote
up vote
0
down vote
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 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.]
answered Oct 22 at 19:18
CMP
653610
653610
add a comment |
add a comment |
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Some of your past answers have not been well-received, and you're in danger of being blocked from answering.
Please pay close attention to the following guidance:
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f48994836%2fchrome-devtools-dedicated-node-js-inspector-not-stopping-at-breakpoints%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown