phantom breakpoints

[MannyC]

v0.7.0

It's breaking on old breakpoints that are no longer in the Breakpoints list. These breakpoints are actually from previous instantiations of both NI and the process being debugged. As they aren't in the list, I cannot disable them using the checkbox method. It does populate the Breakpoints section with some older breakpoints, but these points don't necessarily seem to work, even if they start checked, although some do.

I've tried toggling breakpoints on the phantom lines but no joy.

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

[bajtos]

See How can I (selectively) delete debug session metadata in README.

Before you delete the data, could you please post the content of window.localStorage here, so that I can try to reproduce your problem?

[MannyC]

If you bear with me while I fail to give you the information you've requested :)

window.localStorage.breakpoints all look well formed, and the phantoms are in there.

Now that I've looked at the console, I see that there's a stack trace.

Uncaught TypeError: Cannot call method 'rawLocationToUILocation' of null VM154 BreakpointManager.js:544
WebInspector.BreakpointManager.Breakpoint._didSetBreakpointInDebugger VM154 BreakpointManager.js:544
didSetBreakpoint DebuggerModel.js:228
InspectorBackendClass.dispatch InspectorBackend.js:220
onWebSocketMessage Overrides.js:44

This error appears for each of the broken breakpoints. I did a little bit more digging and it appears that

_breakpointManager._debuggerModel.scripts

is still being populated while this _didSetBreakpointInDebugger method is being run. More scripts appear between invocations and if I check the array manually a little later all the missing scripts are there.

[bajtos]

Thank you for the details, it looks like a race condition. If you can afford to spend some more time on this: could you please run DEBUG=node-inspector:protocol:* node-inspector to enable dump of the communication and see if there is any more information in the protocol messages exchanged? Things to look for: Debugger.scriptParsed, Debugger.setBreakpointByUrl.

[MannyC]

okay, I haven't looked at the node-inspector source at all but this is what I'm seeing in the log:

devtools is the front end, ni is the node inspector process and v8 is the process being debugged.

ni requests scripts from v8
devtools sends the breakpoints to ni.
ni immediately relays the breakpoints to v8
ni recieves scripts from v8 in single message
from here there are many "devtools backend" "Debugger.scriptParsed" messages
in the middle of them ni receives successful "setexceptionbreak" responses from v8
ni immediately sends the setexceptionbreak messages to devtools with the scriptid from the v8 message
scriptParsed messages for the relevant scripts come later.
some of the successful setexceptionbreak responses from v8 come in later, which explains why some work and some don't.

So I guess ni should hold back on relaying the setexceptionbreak message to devtools until it has sent the scriptParsed message for that script.

[MannyC]

This issue appears to stem from 95b68be#diff-b5057ff30170333370f865bfd603e734 when _getSourceMapUrl was introduced with an async.waterfall to allow source maps be retrieved from the process being debugged. Even though in my case the script contents are already in memory, the use of async.waterfall allows the setbreakpoint events to come before the scriptParsed event.

[david-knipe-hp]

As a workaround, you can select "Remove all breakpoints" from the right-click menu in the breakpoints section. (If there are no breakpoints in the list you have to create one first.)