Closed Bug 979571 Opened 10 years ago Closed 10 years ago

Traceback and weirdness when deleting a breakpoint

Categories

(DevTools :: Debugger, defect)

26 Branch
x86
macOS
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED
Firefox 34

People

(Reporter: canuckistani, Assigned: jjurovych)

References

Details

(Keywords: regression)

If I add a breakpoint and then delete it, I get this traceback:

Handler function DebuggerClient.requester threw an exception: Error: 'delete' request packet has no destination.
Stack: DebuggerClient.prototype.request@resource://gre/modules/devtools/dbg-client.jsm:593:7
DebuggerClient.requester/<@resource://gre/modules/devtools/dbg-client.jsm:335:1
makeInfallible/<@resource://gre/modules/devtools/DevToolsUtils.jsm -> resource://gre/modules/devtools/DevToolsUtils.js:80:7
Breakpoints.prototype.removeBreakpoint/<@chrome://browser/content/devtools/debugger-controller.js:1928:7
resolve@resource://gre/modules/commonjs/toolkit/loader.js -> resource://gre/modules/commonjs/sdk/core/promise.js:118:11
then@resource://gre/modules/commonjs/toolkit/loader.js -> resource://gre/modules/commonjs/sdk/core/promise.js:43:43
then@resource://gre/modules/commonjs/toolkit/loader.js -> resource://gre/modules/commonjs/sdk/core/promise.js:153:9
Breakpoints.prototype.removeBreakpoint@chrome://browser/content/devtools/debugger-controller.js:1926:5
Breakpoints.prototype._onEditorBreakpointRemove@chrome://browser/content/devtools/debugger-controller.js:1750:5
EventEmitter_emit@resource://gre/modules/commonjs/toolkit/loader.js -> resource://gre/modules/devtools/event-emitter.js:126:11
removeBreakpoint@resource://gre/modules/commonjs/toolkit/loader.js -> resource:///modules/devtools/sourceeditor/debugger.js:153:3
DebuggerView._initializeEditor/<@chrome://browser/content/devtools/debugger-view.js:241:9
EventEmitter_emit@resource://gre/modules/commonjs/toolkit/loader.js -> resource://gre/modules/devtools/event-emitter.js:126:11
Editor.prototype.appendTo/onLoad/<@resource://gre/modules/commonjs/toolkit/loader.js -> resource:///modules/devtools/sourceeditor/editor.js:304:9
signalLater/bnd/window.CodeMirror@chrome://browser/content/devtools/codemirror/codemirror.js:5498:40
endOperation@chrome://browser/content/devtools/codemirror/codemirror.js:1428:59
operation/window.CodeMirror@chrome://browser/content/devtools/codemirror/codemirror.js:1437:29
Line: 593, column: 6
It works for me on this page using Firefox 27 (and 30, I don't have 26 here).
I cannot reproduce it and re-starting cured the problem, my best guess is that the debugger got into a state ( after a few hours of heavy use ) where it starts to have problems like this. Feel free to close for now.
Reopen if anyone can find a testcase/STR.
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → WORKSFORME
I've found a way to reliably reproduce this. I'm on fx-team tip plus the patch from bug 978019, but I'm pretty sure it's not a regression from that patch. What we need is any page with a script that executes when the page loads and then gets garbage-collected.

Setting a breakpoint on a script that no longer exists will cause the 'setBreakpoint' protocol request to return a 'noScript' error, but will cache the breakpoint on the server to be applied on page reload. This caching seems to be broken and trying to remove the breakpoint results in the stack trace Jeff posted above.

More formal STR:
0. Enable devtools.debugger.log and start Firefox from the terminal.
1. Open file:///[path-to-your-fx-team-repo]/browser/devtools/debugger/test/doc_breakpoints-break-on-last-line-of-script-on-reload.html (you need to apply the patch in bug 978019, or wait for it to land first).
2. Open the debugger and wait a few seconds, just to give the GC a chance to kick in. If you don't see any scripts reload the page and wait a bit.
3. Set a breakpoint at line 4.
4. If the response you see in the terminal to the 'setBreakpoint' request was not a 'noScript' error, remove breakpoint, reload, wait a bit and go back to 3.
5. If you see the 'noScript' error, try to remove the breakpoint (or even close the toolbox or the browser - you'll just get a slightly different stack trace).
Status: RESOLVED → REOPENED
Keywords: regression
Resolution: WORKSFORME → ---
The patch in bug 897567 fixes this.
Status: REOPENED → RESOLVED
Closed: 10 years ago10 years ago
Resolution: --- → FIXED
Assignee: nobody → jjurovych
Target Milestone: --- → Firefox 34
QA Whiteboard: [qa-]
Product: Firefox → DevTools
You need to log in before you can comment on or make changes to this bug.