You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Breakpoints Sometimes not resolving with Node 6.1.0 #934
changed the title [-]Breakpoints not resolving with Node 6.1.0 in other files[/-][+]Breakpoints not resolving with Node 6.1.0 in files besides main[/+]on May 9, 2016
Quick update: The root cause seems to be a change on the node side of things, not in NTVS directly , but it is possible we were relying on bugged behavior previously. The issue is nondeterministic and more common on larger projects. I believe it also exists in Node 6.0.
More specifically, here's how the flow currently works with for a new express app with the breakpoint in routes\index.js:
Launch node with --nolazy --debug-brk
Attach and request scripts from debugger.
We hit hit initial breakpoint on first line of main file since debug-brk is passed in.
Request backtrace from debugger
We set an initial breakpoint using the script name:
DebuggerConnection: Request: {"command":"setbreakpoint","seq":5,"type":"request","arguments":{"line":5,"column":4,"type":"script","target":"C:\\Users\\matb.REDMOND\\Documents\\Visual Studio 2015\\Projects\\ExpressApp6\\ExpressApp6\\routes\\index.js"}}
DebuggerConnection: Response: {"seq":6,"request_seq":5,"type":"response","command":"setbreakpoint","success":true,"body":{"type":"scriptName","breakpoint":2,"script_name":"C:\\Users\\matb.REDMOND\\Documents\\Visual Studio 2015\\Projects\\ExpressApp6\\ExpressApp6\\routes\\index.js","line":5,"column":4,"actual_locations":[]},"refs":[],"running":false}
[21:50:45.6560253] AD7Engine Event: Microsoft.NodejsTools.Debugger.DebugEngine.AD7BreakpointErrorEvent (abb0ca42-f82b-4622-84e4-6903ae90f210)
This breakpoint does not resolve properly according to our logic (actual_locations is empty.) At this point, the script in question has not been fully loaded yet (We have not seen an afterCompile event emitted for it.) This happens in both 5.9 and 6.x
We then request continue. This resumes from the main file on line zero .
A bunch of afterCompile events and other stuff happens. Pretty much identical between node versions.
Things diverge here. On 5.9, we hit the breakpoint set in the index.js file. On 6.x, we never hit anything.
On 5.9, when node hits the breakpoint, we process the event. The breakpoint we set in step 5 is not understood to be fully bound by our code (even though it is fully bound in node). In ProcessBreakpointBreakAsync, we therefore destroy the existing breakpoint and recreate it based on script_id instead (176 is the id of routes/index.js):
To summarize, the core problem seems to be that the first breakpoint we set using the script name does not get picked up by Node. How our code deal with fully bound is a bit odd, and this even causes us to print an error message, but I think this is a red herring.
One other curious note: script paths are all lowercase in node 5.9 but properly cased in Node 6.0:
6.1: C:\\Users\\matb.REDMOND\\Documents\\Visual Studio 2015\\Projects\\node6debugtest\\node6debugtest\\app.js
5.9: c:\\users\\matb.redmond\\documents\\visual studio 2015\\Projects\\node6debugtest\\node6debugtest\\app.js
I'll investigate to see if this is the root cause.
changed the title [-]Breakpoints not resolving with Node 6.1.0 in files besides main[/-][+]Breakpoints Somtimes not resolving with Node 6.1.0[/+]on May 24, 2016
The path differences don't seem to matter. I tried using a case insensitive regex to match the file name when setting the initial breakpoint, and using a file path with no case differences except for the drive letter. These seem unrelated to the breakpoint being hit or not.
Also, I see the backtrace trigger Internal error: illegal access both when breakpoints are hit and when they are not. Setting the breakpoint inside of the express router seems to be a reliable trigger:
router.get('/',function(req,res){res.render('index',{title: 'Express'});// set breakpoint here});
This suggests the illegal access problem is unrelated, which seems to be the conclusion of the Node-inspector thread too. It looks like there is a fix in V8 already that is getting pulled into node: nodejs/node#6928
Activity
[-]Breakpoints not resolving with Node 6.1.0[/-][+]Breakpoints not resolving with Node 6.1.0 in other files[/+][-]Breakpoints not resolving with Node 6.1.0 in other files[/-][+]Breakpoints not resolving with Node 6.1.0 in files besides main[/+]NoelAbrahams commentedon May 16, 2016
Any idea when this is likely to be resolved? This issue is blocking our adoption of Node 6.1 so would appreciate a fix soon. Thanks.
mjbvz commentedon May 16, 2016
I'm looking into this, but right now it is not clear what changed on the Node side of things or what the root cause of the problem is.
mjbvz commentedon May 23, 2016
Quick update: The root cause seems to be a change on the node side of things, not in NTVS directly , but it is possible we were relying on bugged behavior previously. The issue is nondeterministic and more common on larger projects. I believe it also exists in Node 6.0.
I'm seeing several different behaviors:
Internal error: illegal access"when hit and we callbacktrace(possibly related: Internal Error: Illegal Access node-inspector/node-inspector#864 )More specifically, here's how the flow currently works with for a new express app with the breakpoint in
routes\index.js:Launch node with
--nolazy --debug-brkAttach and request
scriptsfrom debugger.We hit hit initial breakpoint on first line of main file since
debug-brkis passed in.Request
backtracefrom debuggerWe set an initial breakpoint using the script name:
This breakpoint does not resolve properly according to our logic (
actual_locationsis empty.) At this point, the script in question has not been fully loaded yet (We have not seen anafterCompileevent emitted for it.) This happens in both 5.9 and 6.xWe then request
continue. This resumes from the main file on line zero .A bunch of
afterCompileevents and other stuff happens. Pretty much identical between node versions.Things diverge here. On 5.9, we hit the breakpoint set in the
index.jsfile. On 6.x, we never hit anything.On 5.9, when node hits the breakpoint, we process the event. The breakpoint we set in step 5 is not understood to be fully bound by our code (even though it is fully bound in node). In
ProcessBreakpointBreakAsync, we therefore destroy the existing breakpoint and recreate it based on script_id instead (176 is the id ofroutes/index.js):To summarize, the core problem seems to be that the first breakpoint we set using the script name does not get picked up by Node. How our code deal with fully bound is a bit odd, and this even causes us to print an error message, but I think this is a red herring.
One other curious note: script paths are all lowercase in node 5.9 but properly cased in Node 6.0:
I'll investigate to see if this is the root cause.
[-]Breakpoints not resolving with Node 6.1.0 in files besides main[/-][+]Breakpoints Somtimes not resolving with Node 6.1.0[/+][-]Breakpoints Somtimes not resolving with Node 6.1.0[/-][+]Breakpoints Sometimes not resolving with Node 6.1.0[/+]mjbvz commentedon May 24, 2016
Update on some of the earlier leads:
The path differences don't seem to matter. I tried using a case insensitive regex to match the file name when setting the initial breakpoint, and using a file path with no case differences except for the drive letter. These seem unrelated to the breakpoint being hit or not.
Also, I see the backtrace trigger
Internal error: illegal accessboth when breakpoints are hit and when they are not. Setting the breakpoint inside of the express router seems to be a reliable trigger:This suggests the illegal access problem is unrelated, which seems to be the conclusion of the Node-inspector thread too. It looks like there is a fix in V8 already that is getting pulled into node: nodejs/node#6928
Fix Node 6 Debugging
mousetraps commentedon Jun 21, 2016
This fix is available in v1.2 beta. Please try it out and let us know what you think! https://aka.ms/ntvslatest
NoelAbrahams commentedon Jun 22, 2016
We've been trying out 1.2 beta with Node 6.2 and the breakpoints seem to be working so far. Thanks.