Node debug Step Over/Into hangs in 1.9

[chiangf]

• VSCode Version: 1.9
• OS Version: 10.12.3

Steps to Reproduce:

1. Set a breakpoint and start debugging node process
2. After breakpoint is hit, just try to Step Over (F10) or Step Into (F11) and both will hang. However, if you set a breakpoint on the next line, and do Continue (F5), it'll continue.

This did not happen in 1.8.1 but started happening right after 1.9.

[wshirey]

Also having this issue.

[angelo-hub]

Also having issues with the debugger becoming unresponsive and hanging.

[weinand]

Which version of node are you using?

Which version of the node debugger are you using? node or node2?
If you are using node, please try node2 and see whether this makes a difference (and vice versa).

[wshirey]

binary versions

$ node -v
v5.8.0

$ node-debug -v
Node Inspector v0.12.7

launch.json config

{
  "version": "0.2.0",
  "configurations": [

    {
      "type": "node",
      "request": "launch",
      "name": "Launch Program",
      "program": "${workspaceRoot}/index.js",
      "cwd": "${workspaceRoot}"
    },
    {
      "type": "node",
      "request": "attach",
      "name": "Attach to Process",
      "port": 5858
    }
  ]
}

[weinand]

@wshirey what OS is this?
Does it make a difference if you change the debug type from 'node' to 'node2'?

[wshirey]

macOS 10.12.2

If I change the type property to type2 property in the configurations object list, I get prompted for what environment I want to debug.

[weinand]

oops, sorry, I mistyped... It should have read:
Does it make a difference if you change the debug type from 'node' to 'node2'?

[wshirey]

Debugger immediately quits.

[weinand]

@wshirey makes sense, since you said above that you are using node v5.8.

[chiangf]

I'm using node v6.9.5 with OSX 10.12.3

I've tried both node and node2 but both have the same behavior.

[weinand]

We are not able to reproduce this problem.

Do you you have a minimal repro that we can try?

Can you try to run VS Code without extensions? From the command line, execute: code --disable-extensions and try your steps again to see if it reproduces.

[adelphes]

For me, this issue appears to be related to the number & size of the local variables. In particular, creating large objects (not arrays) causes the debugger to hang a lot when breakpoints are hit - and for some reason it does seem to be worse in 1.9.

I have since changed my configuration to node2 which improves things, but I do still occasionally find the debugger hangs - and when it does, the only option is to terminate and start again.

[chiangf]

That's similar to what I'm finding too. For simple node scripts, it usually doesn't hang (although occasionally it does). But with a more complex express app with async.js etc., it hangs every time.

[weinand]

Please post a screenshot of the debugger UI when it hangs.

[wmc777]

I think this might be the same issue as #20608

[adelphes]

This problem appears to be related to watches. Adding a watch causes the debugger to hang on a step command; removing all watches makes it work again.
Not sure if this is the same issue everyone else is experiencing, but here's a video of it happening - in the first part, I'm successfully stepping into forEach; I terminate, add a watch and run the same program - it then hangs when stepping into the same forEach.

[Eli-Goldberg]

Having the same issue for a while now,
For me it happens randomly, mostly when lots of memory is in use.

[adelphes]

FYI @weinand @roblourens
OK, so I finally got tired of this issue and debugged the node2 debugger to see what was happening.
And tbh, I was pretty disappointed by what I found.

The issue has already been logged and "fixed": microsoft/vscode-chrome-debug-core#148

I say "fixed" because the issue is a timing problem - what's happening is that the exact order of the step, resume, evaluate and pause events change depending upon how much work is going on in the process.
The change applied to fix this is to wait for an arbitrary 50ms before trying to perform the evaluation.
Seriously guys - this is lazy development; you can't fix a timing issue by saying "we'll just wait for a few milliseconds and hope for the best"

I expected much better from Microsoft.

Can you please fix this. And not by increasing the delay - make the adaptor robust enough to handle events in any order.

[roblourens]

It's really a V8 bug, I was able to repro this in Chrome devtools too - I expected better from Google :P

@isidorn Did anything change in 1.9 about when the evaluate request for a watch is sent after a step?

[isidorn]

@roblourens no, as far as I am aware.

[roblourens]

Ok, I'll look at this again and see if there's a better fix.

[roblourens]

I went back to investigate this and it seems to have been fixed by #21524, with or without my timing hack. Now we don't globally eval watches, and while stepping, the eval request is only sent once the debug adapter has successfully paused. Would appreciate it if you try it out in the Insiders build and let me know.

[chrmarti]

Could someone on this thread who saw this problem confirm it is fixed with the latest insiders builds?

I tried to verify it, but I cannot reproduce in 1.10.2, so I cannot tell for sure if it is fixed.

[chiangf]

I'm on 1.10.2 and it looks fixed to me, 👍

[Eli-Goldberg]

I was getting thit A LOT, seems fixed.
Thanks !!