Node debug Step Over/Into hangs in 1.9 #19841

Closed
chiangf opened this Issue Feb 3, 2017 · 25 comments

Comments

Projects
None yet
10 participants
@chiangf

chiangf commented Feb 3, 2017

  • 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

This comment has been minimized.

Show comment
Hide comment
@wshirey

wshirey Feb 3, 2017

Also having this issue.

wshirey commented Feb 3, 2017

Also having this issue.

@AngefloMusic

This comment has been minimized.

Show comment
Hide comment
@AngefloMusic

AngefloMusic Feb 3, 2017

Also having issues with the debugger becoming unresponsive and hanging.

Also having issues with the debugger becoming unresponsive and hanging.

@weinand

This comment has been minimized.

Show comment
Hide comment
@weinand

weinand Feb 3, 2017

Member

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

Member

weinand commented Feb 3, 2017

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

@weinand weinand added the debug label Feb 3, 2017

@wshirey

This comment has been minimized.

Show comment
Hide comment
@wshirey

wshirey Feb 6, 2017

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
    }
  ]
}

wshirey commented Feb 6, 2017

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

This comment has been minimized.

Show comment
Hide comment
@weinand

weinand Feb 6, 2017

Member

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

Member

weinand commented Feb 6, 2017

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

@wshirey

This comment has been minimized.

Show comment
Hide comment
@wshirey

wshirey Feb 6, 2017

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.

screen shot 2017-02-06 at 11 08 40 am

wshirey commented Feb 6, 2017

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.

screen shot 2017-02-06 at 11 08 40 am

@weinand

This comment has been minimized.

Show comment
Hide comment
@weinand

weinand Feb 6, 2017

Member

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

Member

weinand commented Feb 6, 2017

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

@wshirey

This comment has been minimized.

Show comment
Hide comment
@wshirey

wshirey Feb 6, 2017

Debugger immediately quits.

screenshot 2017-02-06 11 14 49

wshirey commented Feb 6, 2017

Debugger immediately quits.

screenshot 2017-02-06 11 14 49

@weinand

This comment has been minimized.

Show comment
Hide comment
@weinand

weinand Feb 6, 2017

Member

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

Member

weinand commented Feb 6, 2017

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

@chiangf

This comment has been minimized.

Show comment
Hide comment
@chiangf

chiangf Feb 9, 2017

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.

chiangf commented Feb 9, 2017

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

This comment has been minimized.

Show comment
Hide comment
@weinand

weinand Feb 9, 2017

Member

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.

Member

weinand commented Feb 9, 2017

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

This comment has been minimized.

Show comment
Hide comment
@adelphes

adelphes Feb 9, 2017

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.

adelphes commented Feb 9, 2017

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

This comment has been minimized.

Show comment
Hide comment
@chiangf

chiangf Feb 9, 2017

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.

chiangf commented Feb 9, 2017

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

This comment has been minimized.

Show comment
Hide comment
@weinand

weinand Feb 9, 2017

Member

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

Member

weinand commented Feb 9, 2017

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

@wmc777

This comment has been minimized.

Show comment
Hide comment
@wmc777

wmc777 Feb 14, 2017

I think this might be the same issue as #20608

wmc777 commented Feb 14, 2017

I think this might be the same issue as #20608

@adelphes

This comment has been minimized.

Show comment
Hide comment
@adelphes

adelphes Feb 16, 2017

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

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

@Eli-Goldberg

This comment has been minimized.

Show comment
Hide comment
@Eli-Goldberg

Eli-Goldberg Feb 20, 2017

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

image

Eli-Goldberg commented Feb 20, 2017

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

image

@adelphes

This comment has been minimized.

Show comment
Hide comment
@adelphes

adelphes Feb 20, 2017

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.

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

This comment has been minimized.

Show comment
Hide comment
@roblourens

roblourens Feb 20, 2017

Member

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?

Member

roblourens commented Feb 20, 2017

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

This comment has been minimized.

Show comment
Hide comment
@isidorn

isidorn Feb 21, 2017

Contributor

@roblourens no, as far as I am aware.

Contributor

isidorn commented Feb 21, 2017

@roblourens no, as far as I am aware.

@roblourens

This comment has been minimized.

Show comment
Hide comment
@roblourens

roblourens Feb 22, 2017

Member

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

Member

roblourens commented Feb 22, 2017

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

@roblourens roblourens self-assigned this Feb 22, 2017

@roblourens

This comment has been minimized.

Show comment
Hide comment
@roblourens

roblourens Mar 2, 2017

Member

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.

Member

roblourens commented Mar 2, 2017

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

This comment has been minimized.

Show comment
Hide comment
@chrmarti

chrmarti Mar 31, 2017

Contributor

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.

Contributor

chrmarti commented Mar 31, 2017

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

This comment has been minimized.

Show comment
Hide comment
@chiangf

chiangf Apr 1, 2017

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

chiangf commented Apr 1, 2017

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

@Eli-Goldberg

This comment has been minimized.

Show comment
Hide comment
@Eli-Goldberg

Eli-Goldberg Apr 1, 2017

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

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

@Microsoft Microsoft locked and limited conversation to collaborators Nov 18, 2017

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.