Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Debugging v8.5 - always pauses in async_hooks.js on promise rejection #15464

Closed
roblourens opened this issue Sep 19, 2017 · 52 comments
Closed

Debugging v8.5 - always pauses in async_hooks.js on promise rejection #15464

roblourens opened this issue Sep 19, 2017 · 52 comments
Labels
async_hooks Issues and PRs related to the async hooks subsystem. confirmed-bug Issues with confirmed bugs. inspector Issues and PRs related to the V8 inspector protocol promises Issues and PRs related to ECMAScript promises.

Comments

@roblourens
Copy link

roblourens commented Sep 19, 2017

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".

@mscdex mscdex added async_hooks Issues and PRs related to the async hooks subsystem. inspector Issues and PRs related to the V8 inspector protocol promises Issues and PRs related to ECMAScript promises. v8.x labels Sep 19, 2017
@TheAkio
Copy link

TheAkio commented Sep 19, 2017

Seeing the same issue

@kokeksibir
Copy link

Same issue here while debuging with WebStorm 2017.2.4

@eugeneo
Copy link
Contributor

eugeneo commented Sep 20, 2017

CC: @ak239

@gunins
Copy link

gunins commented Sep 20, 2017

Same issue here while debuging with WebStorm 2017.2.4

@benjamingr
Copy link
Member

cc @addaleax

@jpike88
Copy link

jpike88 commented Sep 28, 2017

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

@roblourens
Copy link
Author

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
Copy link

@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
Copy link

nanshakov commented Sep 29, 2017

and in Visual Studio current, not try fix

@TheAkio
Copy link

TheAkio commented Sep 29, 2017

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

@maximilianschmid
Copy link

maximilianschmid commented Oct 2, 2017

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

@nurtom
Copy link

nurtom commented Oct 2, 2017

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

@targos targos added the confirmed-bug Issues with confirmed bugs. label Oct 2, 2017
@alexkozy
Copy link
Member

alexkozy commented Oct 2, 2017

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: #15740

kisg pushed a commit to paul99/v8mips that referenced this issue Oct 3, 2017
In V8Debugger code we don't expect task_id == null, e.g.
asyncTaskStartedForStepping will trigger debug break on null as task_id.
Let's filter task_id == null out.

This issue is originally filed in Node.js:
nodejs/node#15464

R=dgozman@chromium.org

Bug: none
Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel
Change-Id: Icc9f96105b3c91ee1b102d545a7817f7ee93394c
Reviewed-on: https://chromium-review.googlesource.com/695808
Reviewed-by: Dmitry Gozman <dgozman@chromium.org>
Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48265}
@ashantyk
Copy link

ashantyk commented Oct 3, 2017

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

@MattMorgis
Copy link

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

@alexkozy
Copy link
Member

alexkozy commented Oct 6, 2017

Fix for this problem: #15740
Or we can back port landed to V8 patch: v8/v8@f4a2b7f

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

erinishimoticha pushed a commit to erinishimoticha/node that referenced this issue Oct 6, 2017
Original commit message:
    should ignore asyncTask* with null

    In V8Debugger code we don't expect task_id == null, e.g.
    asyncTaskStartedForStepping will trigger debug break on null as task_id.
    Let's filter task_id == null out.

    This issue is originally filed in Node.js:
    nodejs#15464

    R=dgozman@chromium.org

    Bug: none
    Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel
    Change-Id: Icc9f96105b3c91ee1b102d545a7817f7ee93394c
    Reviewed-on: https://chromium-review.googlesource.com/695808
    Reviewed-by: Dmitry Gozman <dgozman@chromium.org>
    Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org>
    Cr-Commit-Position: refs/heads/master@{nodejs#48265}

Fixes nodejs#15464
MylesBorins pushed a commit that referenced this issue Oct 7, 2017
Original commit message:
    should ignore asyncTask* with null

    In V8Debugger code we don't expect task_id == null, e.g.
    asyncTaskStartedForStepping will trigger debug break on null as task_id.
    Let's filter task_id == null out.

    This issue is originally filed in Node.js:
    #15464

    R=dgozman@chromium.org

    Bug: none
    Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel
    Change-Id: Icc9f96105b3c91ee1b102d545a7817f7ee93394c
    Reviewed-on: https://chromium-review.googlesource.com/695808
    Reviewed-by: Dmitry Gozman <dgozman@chromium.org>
    Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org>
    Cr-Commit-Position: refs/heads/master@{#48265}

Fixes #15464

PR-URL: #16053
Reviewed-By: Myles Borins <myles.borins@gmail.com>
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: Gibson Fahnestock <gibfahn@gmail.com>
Reviewed-By: Ali Ijaz Sheikh <ofrobots@google.com>
Reviewed-By: Michaël Zasso <mic.besace@gmail.com>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
@matrixapps
Copy link

process.version
"v8.11.4"

@MattMorgis
Copy link

@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
Copy link

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

@accimeesterlin
Copy link

I did this:

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

and install the latest version of vscode

and it works for me. I hope that helps.

@reyou
Copy link

reyou commented Oct 28, 2018

People dealing with async/await debugging craziness try:

.vscode\launch.json

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

@matrixapps
Copy link

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

Thanks anyway!
Rob

@reyou
Copy link

reyou commented Oct 29, 2018

@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
Copy link

matrixapps commented Oct 29, 2018

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
Copy link

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

@javierlinked
Copy link

will be 3 years soon....

@gslopez
Copy link

gslopez commented Jul 19, 2020

:(

@maxeber
Copy link

maxeber commented Jul 20, 2020

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

@marknorrapscm
Copy link

Also getting this all of a sudden.

image

@Leigh-M
Copy link

Leigh-M commented Jul 23, 2020

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

@DTX-92
Copy link

DTX-92 commented Jul 24, 2020

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
Copy link

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
Copy link

Droppix commented Jul 29, 2020

same issue...

@DillonSadofsky
Copy link

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 <node_internals>

@Leigh-M
Copy link

Leigh-M commented Jul 30, 2020

Yes, I've had to manually skip all of those files (even though they're under <node_internals> 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
Copy link

I can confirm this issue. <node_internals> is not working on skipFiles

@DillonSadofsky
Copy link

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
Copy link

katlimruiz commented Aug 14, 2020

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
Copy link

lokhandechetan commented Aug 17, 2020

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

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

@bendavis78
Copy link

How do you fix this without vsCode when running node via commandline?

@quantuminformation
Copy link

Lol how is this still and issue when debugging with chrome?

@fabioespinosa
Copy link

fabioespinosa commented May 25, 2021

For those struggling with the VS code debugger, this config helped (along with the skipFiles):

"runtimeVersion": "14.9.0",

Apparently it is broken in Node v15

@algotastic
Copy link

I'm using VS Code Insiders via Remote WSL, and I've tried every suggestion in this thread, including many combinations of skipFiles in my launch config as well as switching to the nightly build of the debugger, but I'm still having this issue. microsoft/vscode-js-debug#1085 (as mentioned in #36022) doesn't seem to have fixed it. I'm still brought into "internal\async_hooks" every time I debug. Aside from using an older version of Node (I'm on 16.x), is there a solution for this?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
async_hooks Issues and PRs related to the async hooks subsystem. confirmed-bug Issues with confirmed bugs. inspector Issues and PRs related to the V8 inspector protocol promises Issues and PRs related to ECMAScript promises.
Projects
None yet
Development

Successfully merging a pull request may close this issue.