Node: Debugging v8.5 - always pauses in async_hooks.js on promise rejection

[roblourens]

Have this code:

console.log('before');
Promise.reject(new Error('error'))

When I debug it in Chrome Devtools or VS Code, even when it's set to not break on exceptions, it pauses on function emitDestroyScript(asyncId) {... in async_hook.js after the promise is rejected.

The stack where it pauses is

emitDestroyScript (async_hooks.js:436)
_tickCallback (next_tick.js:175)
Module.runMain (module.js:667)
startup (bootstrap_node.js:201)
(anonymous function) (bootstrap_node.js:626)

The reason on the Debugger.paused message is "other".

[TheAkio]

Seeing the same issue

[kokeksibir]

Same issue here while debuging with WebStorm 2017.2.4

[eugeneo]

CC: @ak239

[gunins]

Same issue here while debuging with WebStorm 2017.2.4

[benjamingr]

cc @addaleax

[jpike88]

This is driving me absolutely mental. Anyone got any ideas?

[roblourens]

This also reproes in Node 8.6. Is anyone looking into this? Seems to be affecting quite a few people.

If anyone is dealing with this in VS Code, there is a workaround - add

"skipFiles": [
    "<node_internals>/**"
],

to your launch config to skip over this file automatically.

[Jeff-Li-Realster]

@roblourens After I added the "skipFiles" to config, it starts to pause on this line every time:

function rejected(value) { try { step(generator["throw"](value)); } catch (e) { reject(e); } }

[nanshakov]

and in Visual Studio current, not try fix

[TheAkio]

For me the quick fix works on Node 8.6 with latest VSCode on Ubuntu 17.04

[maximilianschmid]

Same issue here while debugging NodeJS 8.6 with WebStorm 2017.2.4 on MacOS 10.13

[nurtom]

Same issue with Node 8.6 while Debugging with PhpStorm 2017.2.4 on WIndows Server 2012

[ak239]

I debugged this one. On Inspector side we consider zero async_task_id as not valid task id and are not expecting to get this as asyncTaskStarted API argument. Task id zero triggers DebugBreak on inspector side.
Inspector fix: https://chromium-review.googlesource.com/c/v8/v8/+/695808
Potential Node.js fix: https://github.com/nodejs/node/pull/15740

[ashantyk]

same issue here. webstorm 2017.2.4 & node 8.6 on ubuntu 16.04

[MattMorgis]

Maybe some more movement on this? Created a sample project to help reproduce this, as requested in this thread.

[ak239]

Fix for this problem: https://github.com/nodejs/node/pull/15740
Or we can back port landed to V8 patch: https://github.com/v8/v8/commit/f4a2b7f3e015f94c9bbfc14a7347bc5fac750d81

Ideal solution requires better understanding what does mean zero async task id in Node.js.

[refack]

/cc @nodejs/async_hooks

[roblourens]

Thanks!

[JesseObrien]

Seeing this issue in Google Chrome Version 61.0.3163.100 (Official Build) (64-bit) on OSX Version 10.13 (17A365).

[MattMorgis]

@JesseObrien This was deployed in Node v8.7. Can you confirm you are running v8.7?

[umbrella-ivan-zhukov]

All is working after update to the latest stable nodeJS.
Mac 10.12.6
WebStorm 2017.2.5
Node v9.2.0

[matrixapps]

Has anyone solved this issue that is quite infuriating. VSCODE 1.27.1 with Node 8.11.4.
Using my typical debug workflow and the function emitInitNative gets broken into constantly. I've tried the suggestions in launch code , but to no avail. Any other ideas? Driving me nuts.
```
"skipFiles": [
"${workspaceFolder}/nodeApp/node_modules//.js",
"${workspaceFolder}/lib//.js",
"//*.js",
"/",
"/internal/async_hooks.js"
],

[MattMorgis]

@matrixapps Sounds like VS Code is sneakily using an older version of Node prior to v8.7. This can happen when using NVM sometimes.

[matrixapps]

Hmm. Running node -v in VScode terminal indicates v8.11.4. Is there somwhere else I need to look or a way to override? This is grinding my testing to a halt (no pun intended!)

[roblourens]

Run process.version in the debug console while debugging

[matrixapps]

process.version
"v8.11.4"

[MattMorgis]

@matrixapps I would suggest opening a new issue and referencing this one. This issue was specifically for v8.5 and you are the first to report an issue after v8.7, so it might be related, but it could be something entirely new.

[matrixapps]

Thanks for the feedback Matt. This is driving me up the wall!

[accimeesterlin]

I did this:

"skipFiles": [
    "<node_internals>/**"
],

and install the latest version of vscode

and it works for me. I hope that helps.

[reyou]

People dealing with async/await debugging craziness try:

.vscode\launch.json

"smartStep": true,
"skipFiles": ["<node_internals>/**"],

[matrixapps]

Hi,
Unfortunately this did not help me. I already had _"skipFiles": ["/**"]_ and thought the addition of _"smartStep": true_ would help, but to no avail. This continues to drive me nuts!

Thanks anyway!
Rob

[reyou]

@matrixapps do you have a minimal test project to look at?
Maybe I can download and try on my local to see if it steps through correctly.

What behavior are you facing with?

[matrixapps]

In my current stack I see that it occurs on a Promise within _lodash.reduce_. I'm not explicitly calling this but its part of a much larger login sequence. The actual breakpoint happens in

if ((DataView && getTag(new DataView(new ArrayBuffer(1))) != dataViewTag) ||
    (Map && getTag(new Map) != mapTag) ||
    >>>>> (Promise && getTag(Promise.resolve()) != promiseTag) ||  <<<<<<<<
    (Set && getTag(new Set) != setTag) ||
    (WeakMap && getTag(new WeakMap) != weakMapTag)) {

My only resolution is to keep breakpoints OFF when I start debugging and then selectively turn them back on. :(

[marktyers]

Over a year later and this has still not been resolved!!!!

[javierlinked]

will be 3 years soon....

[gslopez]

:(

[maxeber]

Has this been addressed? It is also driving me crazy aha

[marknorrapscm]

Also getting this all of a sudden.

[Leigh-M]

Yeah mine's the same.. still stopping on despite being correctly included in the skipFiles launch config

[DTX-92]

Month ago I was good with
"skipFiles": ["${workspaceFolder}/node_modules/**/*.js", "<node_internals>/**"]
But today I tried to step into await function and found myself in async_hooks.js...

[zaidrashid]

I'm on vscode 1.47.3 and having this issue too. I can see that some have commented about this issue like 4/5 days ago so it must be something to do with recent updates? hmm

[Droppix]

same issue...

[DillonSadofsky]

I also started having this happen after a recent VS code update. I thought it had to do with the config of a new project I was working on, but I went back to one that worked a couple months ago and it is experiencing the same thing. I believe skipFiles no longer respects

[Leigh-M]

Yes, I've had to manually skip all of those files (even though they're under which no longer works!) with this:

"skipFiles": [
              "<node_internals>", "node_modules", "loader.js", "async_hooks.js", "bootstrap.js", "**/async_hooks.js", "**/webpack/bootstrap", "**/internal/**/*", "**/domain.js", "**/events.js"
            ],

Very annoying but it works in the short term..

[bernardolk]

I can confirm this issue. is not working on skipFiles

[DillonSadofsky]

For those that are landing on this page because skipFiles no longer works with node_internals, I can verify that these steps:
https://github.com/microsoft/vscode-js-debug#nightly-extension
fixes it. You're essentially switching to the nightly build of the debugger. Presumably this will only be necessary until they update the live debugger.

[katlimruiz]

Yes, it was working with the skipFiles for very long, and suddenly it stoppped working.

I usually did this

            "skipFiles": [
                "${workspaceFolder}/node_modules/**/*.js",
                "<node_internals>/**/*.js"
              ]

I just tried it with the solution above and it can be solved with this too, at least for me it is enough

            "skipFiles": [
                "${workspaceFolder}/node_modules/**/*.js",
                "<node_internals>/**/*.js",
                "**/*async_hook*.js"
              ]

[lokhandechetan]

Following workaround worked for me.
Replace '<' and '>' with * (star) in the following,
"/*/.js",

Looks like there is an issue with recognizing '<>' .
Give it a try.