node --inspect and node --inspect-brk not being connected to by chrome

[tiagosiebler]

• Version:

• node: v8.9.1
• chrome: Version 73.0.3683.86 (Official Build) (64-bit)

• Platform: macOS,
  Darwin tsbook 18.2.0 Darwin Kernel Version 18.2.0: Fri Oct 5 19:41:49 PDT 2018; root:xnu-4903.221.2~2/RELEASE_X86_64 x86_64

• Subsystem:

I recently updated google chrome to the latest version. Normally for debugging during dev, I:

• go to chrome://inspect/#devices in chrome
• click "Open dedicated Dev Tools for node":

As soon as I launch any node process in terminal using either node --inspect or node --inspect-brk, within a few seconds my open dev tools window will connect.

I see this in the console:

$ node --inspect-brk test.js
Debugger listening on ws://127.0.0.1:9229/543b49e3-8e6a-479e-b125-39f4252120a4
For help see https://nodejs.org/en/docs/inspector

I see this in dev tools:

Yet the dedicated window remains unconnected:

Things I've tried:

• launch with --inspect-brk=127.0.0.1:9229
• launch with --inspect-brk=localhost:9229
• uncheck -> check "discover network targets"
• click "inspect" on target that's seen. It opens a window, but remains unconnected.

How can I troubleshoot this? Bit stuck without it. Tried brave too, since it's the same engine, same behaviour.

Thanks in advance.

[vsemozhetbyt]

cc @nodejs/v8-inspector
See also the last messages in #23693

[tiagosiebler]

Thanks @vsemozhetbyt, so either downgrade chrome to 72, or use node 11? Did I understand the workaround correctly?

[vsemozhetbyt]

Let's also see what @nodejs/v8-inspector thinks.

[tiagosiebler]

Just tried google canary. Looks like I can "inspect" a running process, but I can't automatically connect with the dedicated dev tools window. Guess it's still in the nightly builds too, curious what v8^ thinks. Thanks for helping.

[june07]

Try NiM https://june07.com/nim and see this post regarding how to mix DevTools/Chrome versions https://blog.june07.com/nim-custom-devtools-url

[pavelfeldman]

@dgozman, what did we break? Is it your flat protocol refactoring?

[ianfdk]

Got the same problem. Dedicated DevTools does not attach. It immediately connects to the Remote Target

EDIT:
A bit more info on my setup

Google Chrome	73.0.3683.86 (Official Build) (64-bit)
Revision	f9b0bec6063ea50ce2b71f5b9abbae7beee319a6-refs/branch-heads/3683@{#858}
OS	Mac OS X
JavaScript	V8 7.3.492.25
User Agent	Mozilla/5.0 (Macintosh; Intel Mac OS X 10_14_3) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/73.0.3683.86 Safari/537.36

Temporary fix
With the NiM plugin (thanks @june07) in "auto" mode, I get almost the same behaviour that I'm used to. Only difference is that the debugger window will attach when I focus on it instead of attaching automatically and bringing that Chrome window to the front.

[michaloslav]

I'm having the same exact problem so I started debuging using VS Code which works fine. That most likely means that it's not a Node problem but a Chrome problem (in case that wasn't clear already)

[stoplion]

+1 Same problem

[DyckGerman]

@tiagosiebler , @stoplion did you try different port?
I had a connectivity issue on windows 10 and solved it by switching to non default port
--inspect-brk=127.0.0.1:8888
then added that port via "Configure..." for "Discover network targets"

[tiagosiebler]

@DyckGerman yes, I do see the running process as well. If I open the dedicated DevTools for Node, I see in the node app's console that the debugger's attached, but the DevTools window remains unaffected.

If I manually click "inspect" on one of the targets in the "Remote Target" list, that successfully connects and lets me use DevTools. It's a weird quirk introduced in a recent update. Using NiM for chrome has eased the pain a bit, but is definitely annoying (I have workers launching on different ports, and it's a pain to edit the port number constantly).

[june07]

NiM has the ability to manage multiple ports now. https://blog.june07.com/nim-tabs/

…

On Sun, Apr 21, 2019, 9:11 AM Tiago ***@***.***> wrote: @DyckGerman <https://github.com/DyckGerman> yes, I do see the running process as well. If I open the dedicated DevTools for Node, I see in the node app's console that the debugger's attached, but the DevTools window remains unaffected. If I manually click "inspect" on one of the targets in the "Remote Target" list, that successfully connects and lets me use DevTools. It's a weird quirk introduced in a recent update. Using NiM for chrome has eased the pain a bit, but is definitely annoying (I have workers launching on different ports, and it's a pain to edit the port number constantly). — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#26887 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ACWT35UQSSU5MHR5VRNPQUDPRSGZRANCNFSM4HAV4LNA> .

[tjbulick]

chrome 74, bug is still reproducible on mac os

[alexkozy]

It works just fine to me. I open Chrome 74, go to dedicated frontend, run node --inspect-brk index.js.

[alexkozy]

You can use --inspect as well but in this case if your script is small then frontend connects and disconnects very fast, so --inspect-brk is preferable in this case - node script will stop at breakpoint at first line and you can set other breakpoints or start some profiler if needed.

[spalger]

Yeah, it started working a couple weeks ago for me. This could probably be closed.

[tiagosiebler]

This has stopped happening for me, on brave:

Version 0.64.76 Chromium: 74.0.3729.157 (Official Build) (64-bit)

With node v11.13.0. Started working fine again around a week ago. Feel free to close this.

[cyrus-za]

Still broken for me.

Environment

• Node v11.14.0
• Google Chrome Version 74.0.3729.169 (Official Build) (64-bit)
• OS MacOS Mojave 10.14.4 (18E226)

Using asdf to version my nodejs (doubt that will matter though)

$ asdf current
nodejs 11.14.0

Tried

• node --inspect
• node --inspect-brk
• node --inspect-brk=7007
• node --inspect-brk=localhost:7007
• node --inspect-brk=127.0.0.1:7007

[zardilior]

Still not fixed?

[benag]

i cannot connect remotlly, i run: node app.js --inspect=0.0.0.0:9229 on remote machine
but i cannot see it on chrom inspect.

[june07]

Are you forwarding the inspect socket to your local DevTools instance? Sounds like you may need to do that...

[benag]

Are you forwarding the inspect socket to your local DevTools instance? Sounds like you may need to do that...

I configured in developer tools to listen to the remote machine on 9229

[tristanHessell]

@benag this might sound silly, but I've only got it to work if i have the --inspect command line parameter before the file in the node command.
Ie:

node --inspect app.js # works
node app.js --insepct # does not

[robertkraig]

@benag this might sound silly, but I've only got it to work if i have the --inspect command line parameter before the file in the node command.
Ie:

node --inspect app.js # works
node app.js --insepct # does not

@tristanHessell this solved the issue for me. The order of the parameters matters.

[cyrus-za]

I use NODE_OPTIONS="--inspect" node these days. This can be used with any framework like CRA or nextjs or gatsby etc where they dont expose the underlying node executable.

Same goes for using nodemon and ts-node which usually would require using node --register ts-node just to access the node specific stuff.

I wish I knew about these environment variables sooner as it would have saved me a lot of hassle. I hope it helps others

[chyzwar]

@tristanHessell changing order of --inspect also worked for me.
Orginal issue #11028
Node.js decided to have this broken.... and this flag is order sensitive

IMO docs should be updated as this is a rather common problem.
https://nodejs.org/api/debugger.html

This is so painful. Wasting 2h of my time because of broken node.js CLI.

[gentunian]

@chyzwar putting --inspect after the .js file will treated as an argument for the invoked script, i.e. will never work. Node applications are invoked like this:

node [NODE_OPTIONS] [SCRIPT_FILE] [SCRIPT_ARGUMENTS]

where:

• NODE_OPTIONS: are options for the node command
• SCRIPT_FILE: is the script you want to run
• SCRIPT_ARGUMENTS: are the command line arguments to be put in process.argv array, i.e. the arguments for your program.

No documentation should be updated. You waste 2 hours of your life because you didn't know how to run a node application.

[gentunian]

BTW, if this is useful for anyone that is having this issue, change localhost to 127.0.0.1 in chrome address: chrome://inspect under Devices section clicking on Configure button.

[jasnell]

There does not appear to be anything actionable here.

[cherryshoe]

I have been successful in remote debugging the Node app with an ssh tunnel for over a year, when this issue started happening yesterday. In actuality it likely started approximately July 20, 2020 (I haven't worked on the Node backend code since roughly that time).

Version

• node: v8.11.3

• chrome: Version 84.0.4147.105 (Official Build) (64-bit)

• VM: CentOS Linux release 7.3.1611 (Core)

• Host: Windows 10 Pro (Version 1903, OS build 18362.900, Installed on 10/26/2019)

• Node is started via PM2 for clustering, here is the snippet from the ecosystem.config.js file:
  node_args: '--max-old-space-size=8192 --inspect',

• PM2 log files says the two node processes have debugging listening:
  Debugger listening on ws://127.0.0.1:9230/8dc39538-85f5-41a6-8d26-ebb72fc469b2
  Debugger listening on ws://127.0.0.1:9231/03ee3b6c-d3f8-4aef-a23e-51b403dca357

• SSH tunneling is enabled on both ports:
  ssh -L 8890:127.0.0.1:9230 user@hostname
  ssh -L 8891:127.0.0.1:9231 user@hostname

• Chrome Dev Tools configured with 127.0.0.1
  

• You can see that Dev Tools recognizes the two processes are running but when I click on "inspect" for both processes, the DevTools window doesn't recognize any files, whereas before it could.
  

[uzair004]

same problem

[NikitaBelevich]

During debugging in VS Code, I have this note. But everything works correctly. How may I put away the note?

[june07]

Try NiM https://june07.com/nim and see this post regarding how to mix DevTools/Chrome versions https://blog.june07.com/nim-custom-devtools-url

Bump. Even just as a temporary workaround.

[LowPowerLab]

Bump.

Broken (again?) in Chrome v97. Keep getting this error and breakpoints do not work:
index.js:43 (node:18701) [INSPECTOR_ASYNC_STACK_TRACES_NOT_AVAILABLE] Warning: Warning: Async stack traces in debugger are not available on 32bit platforms. The feature is disabled.

Installing the NiM Chrome extension was my only avenue to resume debugging my remote nodejs instance. It will open a DevTools window which works, and is a little different than Chrome's latest one - regular browser window with address bar and file system view is the old style with the cloud for the remote filesystem:

devtools://devtools/bundled/inspector.html?experiments=true&v8only=true&ws=192.168.0.123:9229/f9b6d912-3d95-483a-a8c7-f186c0bbf54f

I spent about 2hrs trying to figure this out, I hope it helps someone.

[june07]

FYI, the DevTools version is very much customizable using NiM.

https://blog.june07.com/nim-custom-devtools-url/
https://blog.june07.com/devtoolscompat/

As well an Edge version is published for those folks using Microsoft Edge and who would rather install from Edge Add-ons

https://microsoftedge.microsoft.com/addons/detail/nodejs-v8-inspector-ma/injfmegnapmoakbmnmnecjabigpdjeme

[mpcabete]

BTW, if this is useful for anyone that is having this issue, change localhost to 127.0.0.1 in chrome address: chrome://inspect under Devices section clicking on Configure button.

This fixed it for me!! thanks!

[betoharres]

on express, using the binary file along with the --inspect flag worked for me... nodemon --exec node --inspect ./bin/www

it's just sad how fucked up this is, debugging in one of the most popular platforms should be easy; and nodejs and express has been out for years...