-
Notifications
You must be signed in to change notification settings - Fork 30k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
node --inspect ignores debugger statements and breakpoints inside vm.runInContext #12096
Comments
cc @nodejs/diagnostics |
There is a pull request that is trying to address this: #7593 Currently this is all blocked on old debugger getting deprecated/disabled - then we will be able to enable the inspector sooner and track all VM contexts. I will assign this issue to me for now. |
Thanks! Alternately, what's the last version where it would work? |
I do not know if --debug supports multicontext. node debug is a CLI debugger that uses --debug as a protocol. |
--debug works most of the time to debug context as long as you set "debugger" instructions within the code executed in the context. But it is not a very efficient protocol to debug Promises. It would be great if it could be fixed. Anyway we can help? |
This issue a dublicate of #7593 |
This enables inspector support for contexts created using the vm module. Fixes: nodejs#7593 Fixes: nodejs#12096 Refs: nodejs#9272
Did #14465 solve this? |
Verified that in node 8.4.0 the following breaks as expected: node --inspect-brk -e 'vm.runInNewContext("const obj = { log: console.log };\nobj.log(1);\ndebugger;\nobj.log(2);", { console })' I think this is good to close. |
The
chrome-devtools://
view correctly displays the console output, is aware of the files being executed usingvm.runInContext
(withfilename
set), even lets me set breakpoints in them, it just doesn't actually break for them.I forward the outer
console
object into the vm context soconsole.log
statements get correctly printed out by the inspector and I can dig through objects, assign them etc. (though it crashes when accessing certain objects - by the looks of it, it doesn't keep a GC reference to them so they are probably just no longer there).I'm hoping there is a similar mechanism I can use to have the VM's debug context share the outer one?
The text was updated successfully, but these errors were encountered: