Debuging es6 Proxy as property -> Internal error: illegal access

[jiron12]

• VSCode Version: 1.2.1
• OS Version: Windows 10

Steps to Reproduce:

1 - If I, in node.js 6.6, write (resp. have transpiled from TypeScript) a class like that:

 class Table {
    constructor(args) {
         this._rows = new Proxy({ test: 42 }, {});
    }
 }

2 - And then instantiate it like this:

var table = new Table();

3 - When I debug in Visual Studio Code and I want to watch the var table I always have

Internal error: illegal access

written there, meaning I can not watch table or any of its properties.

The same thing works perfectly fine in Chrome.

I have raised this on Stackoverflow:
http://stackoverflow.com/questions/39710014/debuging-es6-proxy-as-property-internal-error-illegal-access

[roblourens]

VSCode 1.2 is rather old, but in the newest version, I see an empty variables pane and that error is thrown internally. Playing with it, it usually works in Chrome devtools but I've seen that error there too -

will address it but probably not for 1.6

[jiron12]

But should I anyway be able to debugg Proxy objects run in node.js in vscode? Because in fact at lest in my case it does not seam to work... when I create a Proxy object as var and not as property I do not see any variables under 'Variables' in the Debugger view at all and when I add one to the watch I see same message on it 'illegal access'.

Btw.: node.js Version 6.7.0

[roblourens]

Yes, it's a bug that it doesn't work.

[jiron12]

I'd be very happy to see this fixed soon.

[weinand]

@roblourens would this work with node2?

[roblourens]

Not for Node 6.x (with the same errors in chrome devtools), but it works in the latest 7 nightlies.

[roblourens]

@weinand This is worse in Node 7 for node-debug - the debugger crashes entirely when there is a Proxy object in scope.

[weinand]

This node crash occurs when retrieving the stack trace through the v8 debugger protocol:

#
# Fatal error in ../deps/v8/src/runtime/runtime-debug.cc, line 1423
# Check failed: args[0]->IsJSObject().
#

==== C stack trace ===============================

    0   node                                0x0000000100bcb6d3 v8::base::debug::StackTrace::StackTrace() + 19
    1   node                                0x0000000100bc8859 V8_Fatal + 233
    2   node                                0x00000001007bdfb6 v8::internal::Runtime_DebugGetPrototype(int, v8::internal::Object**, v8::internal::Isolate*) + 438
    3   ???                                 0x000006b8b4c063a7 0x0 + 7390376256423

There is nothing I can do about this (and node-inspector shows exactly the same behaviour).

[jiron12]

So I understand this is out of your reach? Would you recommend me to file a bug to V8?

[roblourens]

The debug code there is deprecated so it's pretty unlikely to be fixed (and that's why these issues pop up with new JS features). I recommend using "type": "node2" in your launch config to opt-in to the new debug protocol, instead of 'node', and Node v7+, which worked for proxies last I tried.

[weinand]

@roblourens I suggest that you add this info to the November release notes under a "node2 update" item.

[jiron12]

Thank you very much! That works indeed!

Wild times! The new one is still labeled experimental, the old one is already deprecated! :)

[weinand]

@jiron12 no, VS Code's old node debug is not deprecated.
@roblourens statement about the "debug code there is deprecated" was referring to the v8 debug code in node.js itself.

[roblourens]

Documented this in the release notes - closing as upstream

[pannous]

can "type": "node2" be set as default somewhere / for single file debugging ?

[weinand]

@pannous You could try to use this approach: https://code.visualstudio.com/updates/v1_9#_user-level-launchjson

In the next release we will pick the correct debugger automatically.