Vscode-react-native: Breakpoint getting hit in JS, but not being recognized in VS Code when using node 6.X

Created on 29 Jul 2016  路  11Comments  路  Source: microsoft/vscode-react-native

Actual Behavior

  1. Added a breakpoint to a function that handles user input
  2. Adding the breakpoint would lock the device's UI, but doesn't "turn on" debugging

    Expected Behavior

  3. The debugging session to start up, stack traces, variables etc

So I have a simple trivial example, you would need to run npm install then start a debug run for iOS inside VS Code.

https://cl.ly/3C0V2Z2i200l/react-native-debugger-issues.zip

You should tap the view to see it say both "yo" then "hello". If you add a breakpoint at "hello" (line 11) and tap the view, the console will print "yo" but not "hello" - and VS Code will not start showing the trace etc

Software versions

  • React-Native VS Code extension version: 0.1.5
  • VSCode version: 1.3.1
  • OS platform and version: OS X, 10.11.6
  • React Native version: 0.30

/cc @mennenia

bug

Most helpful comment

We've managed to get a stable minimal repro case and sent it to nodejs team, so hopefully they will be able to reproduce and fix this on their end.

@orta, @mennenia, as of now as a workaround _we recommend to use either 4.x or 7.x NodeJS version_ (it appeared that 7.x is also unaffected by this bug and debugging works just fine)

@mbraude, we can probably close this as there is nothing we can do at our end?

All 11 comments

Thanks for reporting this, that's definitely a bug. We recently made some changes that we haven't yet released which update the debugger to a newer version. If you are keen, you could try checking out this codebase and see if your issue reproduces still. Otherwise I'll take a look at this soon and see what's going on.

I just tried out the example you linked above, and it works fine for me with all the same versions (Except I'm on OS X 10.11.4)

Does this fail consistently for you every time?

Yep, just tried it now, 100% reproducible, based on the file uploaded on another computer, same VS Code / React-N setup

screen shot 2016-08-01 at 5 44 24 pm

What version of nodejs do you have installed? node -v should tell you.

I'm running 5.10.1, and the process being debugged is actually running in a node process so a mismatch there may explain the difference in behavior.

This was tested on node version 6.1.0.

Ok, looks like that's the cause, I just reproduced this using node 6.3.1

We are using the vscode-node-debug debugger internally, so I'll let them know and see if we can get a fix out. Thanks for letting us know!

I'm trying to get a minimal example to help the node debugging team analyse the issue. In the mean time though, I did notice that manually pausing the debugger (clicking the pause button) when the execution was already stopped at a breakpoint does cause the debugger to realise it is stopped at the appropriate line and you can debug and continue on. Not the best, but a workaround while we try and sort this out.

Here is an update:

  1. We can confirm that the issue is 100% reproducible with node 6.x. But not with 4.x.
  2. We have observed that the node process has run into the event handler(handleTap) and broke at the requested break point. However the node process never notifies us a breakpoint being hit. Because our debugger is not notified, there is no one to drive the UI to break at the source code. We compared this with a working scenario, (that is, if we set breakpoint outside of a event handler, the breakpoint can be hit), we can receive the break point message correctly.

So this looks like a bug in Node.js itself.

  1. We were trying to get a minimum example for reproduction. We wrote a simple nodejs app to simulate how we do debugging, but it doesn't reproduce there.

Tracking this issue here as well.

We've managed to get a stable minimal repro case and sent it to nodejs team, so hopefully they will be able to reproduce and fix this on their end.

@orta, @mennenia, as of now as a workaround _we recommend to use either 4.x or 7.x NodeJS version_ (it appeared that 7.x is also unaffected by this bug and debugging works just fine)

@mbraude, we can probably close this as there is nothing we can do at our end?

Thanks!

Was this page helpful?
0 / 5 - 0 ratings