Fatal error occurred when hitting breakpoint which use es6 proxy

[hitbear518]

Actual Behavior

1. fatal error occurred when hitting breakpoint which near es6 proxy

Expected Behavior

1. execution stop at breakpoint correctly

Software versions

• React-Native VS Code extension version: 0.2.3
• VSCode version: 1.7.2
• OS platform and version: macOS Sierra 10.12.1
• NodeJS version: 7.2.0
• React Native version: 0.38

Outputs (Include if relevant)

• Output of the Debug Console (View -> Toggle Debug Console):

#
# Fatal error in ../deps/v8/src/runtime/runtime-debug.cc, line 1423
# Check failed: args[0]->IsJSObject().
#
==== C stack trace ===============================
    0   node                                0x00000001009569ed v8::base::debug::StackTrace::StackTrace() + 19
    1   node                                0x0000000100955705 V8_Fatal + 233
    2   node                                0x00000001005d2d56 v8::internal::Runtime_DebugGetPrototype(int, v8::internal::Object**, v8::internal::Isolate*) + 414
    3   ???                                 0x000006d240a063a7 0x0 + 7500097151911

Breakpoint is in WebView callback

onShouldStartLoadWithRequest = (event) => {
    // breakpoint is here
    console.log(event);
}

in normal lines like render, breakpoint works just fine

[MSLaguana]

Unfortunately this looks a lot like a bug in nodejs (specifically in v8 actually): https://bugs.chromium.org/p/v8/issues/detail?id=3270

I also just tried this out in node 6.9.1 and hit what looks like the same issue. Until node/v8 addresses this issue, we won't be able to debug in places where the debugger would inspect a proxy.

[hitbear518]

I found vscode already has a new node debug extension, and there's a similar issue in vscode repo,
hope this will help

[MSLaguana]

The other node debugging extension that you link to there is using an alternative (and currently experimental) way of debugging node.js which is using the same debugging protocol that Chrome uses. I just tested it out and int does look like this particular issue goes away if we were to use the newer debugger under the hood.

That said, the new debugging approach is experimental and subject to change, and it'll take us a bit to move our infrastructure from the current debugger to the new one if we do decide to go that way. We'll have to discuss it and see if there's an alternative approach. Thanks for bringing it to our attention though!

[ssahni]

@MSLaguana How did you test it out? Did you change the type in launch.json? If so, which one did you change?

[MSLaguana]

I didn't test using the debug adapters, I tested the underlying debugging mechanism. It isn't simple to switch the react-native debugging pipeline that we have to one which uses the new debugger protocol, so I can't provide a workaround for now unfortunately.

[ssahni]

Oh ok, understood. It would be greatly appreciated if maybe you could push a branch with your test :-). I would be willing, and I imagine many others would be willing, to use the experimental approach until its fixed properly.

Thanks!

[MSLaguana]

My test was simpler than you think unfortunately: If you create a JS file with contents

var p1 = new Proxy([], {});
setTimeout(function () {
  var p = new Proxy([], {});
  debugger;
}, 100000);

That is enough to show off this particular bug. If you run node debug test.js and step over that first line, go to the repl, then try to print out p1, it'll trigger the bug and crash node. If you use the new debugging method via launching node as node --inspect test.js then navigate chrome to the URL it tells you (hence the timeout to give me a chance to attach) then it can view both variables just fine.

However, to move our debugger on top of the node2 debugger rather than the node debugger will need some investigation into how the new debugger works, make sure that we pass in the required arguments correctly and also ensure that the changes we make for source maps get converted to work with the new, differently structured debugger. That's all work that I haven't looked into yet.

[vladimir-kotikov]

Linking other relevant issues: microsoft/vscode#12749, microsoft/vscode-node-debug#112, #334 (comment)

[vladimir-kotikov]

This issue has been fixed by switching to node2 debugging engine in #390. @MSLaguana, can we close this?