Closed Bug 1189111 Opened 9 years ago Closed 8 years ago

evaluateJSAsync: TypeError: Debugger.Object belongs to a different Debugger

Categories

(DevTools :: Debugger, defect)

defect
Not set
normal

Tracking

(Not tracked)

RESOLVED DUPLICATE of bug 1299602

People

(Reporter: fitzgen, Unassigned, NeedInfo)

References

(Blocks 1 open bug)

Details

No description provided.
This is the full error that I see in the console, with a breakpoint set at DLS_execute DownloadCore.jsm:2402 >> this error occurred while processing 'evaluateJSAsync: TypeError: Debugger.Object belongs to a different Debugger Stack: WCA_evalWithDebugger@resource://gre/modules/commonjs/toolkit/loader.js -> resource://gre/modules/devtools/server/actors/webconsole.js:1192:16 WCA_onEvaluateJS@resource://gre/modules/commonjs/toolkit/loader.js -> resource://gre/modules/devtools/server/actors/webconsole.js:811:20 WCA_onEvaluateJSAsync@resource://gre/modules/commonjs/toolkit/loader.js -> resource://gre/modules/devtools/server/actors/webconsole.js:782:20 DSC_onPacket@resource://gre/modules/commonjs/toolkit/loader.js -> resource://gre/modules/devtools/server/main.js:1593:15 DebuggerTransport.prototype._onJSONObjectReady/<@resource://gre/modules/commonjs/toolkit/loader.js -> resource://gre/modules/devtools/transport/transport.js:479:9 makeInfallible/<@resource://gre/modules/commonjs/toolkit/loader.js -> resource://gre/modules/devtools/DevToolsUtils.js:83:14 makeInfallible/<@resource://gre/modules/commonjs/toolkit/loader.js -> resource://gre/modules/devtools/DevToolsUtils.js:83:14 EventLoop.prototype.enter@resource://gre/modules/commonjs/toolkit/loader.js -> resource://gre/modules/devtools/server/actors/script.js:339:5 ThreadActor.prototype._pushThreadPause@resource://gre/modules/commonjs/toolkit/loader.js -> resource://gre/modules/devtools/server/actors/script.js:534:5 ThreadActor.prototype._pauseAndRespond@resource://gre/modules/commonjs/toolkit/loader.js -> resource://gre/modules/devtools/server/actors/script.js:735:7 BreakpointActor.prototype.hit@resource://gre/modules/commonjs/toolkit/loader.js -> resource://gre/modules/devtools/server/actors/script.js:3310:12 DLS_execute@resource://gre/modules/DownloadCore.jsm:2402:1 task_D_start@resource://gre/modules/DownloadCore.jsm:473:1 TaskImpl_run@resource://gre/modules/Task.jsm:330:41 Handler.prototype.process@resource://gre/modules/Promise.jsm -> resource://gre/modules/Promise-backend.js:934:23 this.PromiseWalker.walkerLoop@resource://gre/modules/Promise.jsm -> resource://gre/modules/Promise-backend.js:813:7 Promise*this.PromiseWalker.scheduleWalkerLoop@resource://gre/modules/Promise.jsm -> resource://gre/modules/Promise-backend.js:744:11 this.PromiseWalker.schedulePromise@resource://gre/modules/Promise.jsm -> resource://gre/modules/Promise-backend.js:776:7 this.PromiseWalker.completePromise@resource://gre/modules/Promise.jsm -> resource://gre/modules/Promise-backend.js:711:7 promiseTargetFile/</<@chrome://global/content/contentAreaUtils.js:643:7 Line: 1192, column: 16 This was a breakpoint I had previously set (where this did work), unset, did some things, then went back and set the breakpoint again (which should trigger upon downloading any file). When attempting to access this, it generates the above error.
This is on the latest fx-team, as of a day or so ago: april@anhedonia(fx-team)$ hg summary parent: 255014:aa144e36fab0 tip Bug 1187443 - [Rule View] Remove preview value on start editing of a property r=bgrins branch: default commit: (clean) update: (current) Note that if I close fx-team (NightlyDebug), reopen it, and set the same breakpoint, it works fine: >> this << Object { deferExecuted: Object, deferCanceled: Object, download: Object, _sha256Hash: null, _signatureInfo: null, _redirects: undefined, request: XPCWrappedNative_NoHelper }
Happened to me today on FF Developer 47.0a2 (2016-04-20). Can't find what triggers it (feels random). Full stack: "onPacket threw an exception: Error: Server did not specify an actor, dropping packet: {"error":"unknownError","message":"error occurred while processing 'evaluateJSAsync: TypeError: Debugger.Object belongs to a different Debugger\nStack: WCA_evalWithDebugger@resource://gre/modules/commonjs/toolkit/loader.js -> resource://devtools/server/actors/webconsole.js:1281:16\nWCA_onEvaluateJS@resource://gre/modules/commonjs/toolkit/loader.js -> resource://devtools/server/actors/webconsole.js:872:20\nWCA_onEvaluateJSAsync@resource://gre/modules/commonjs/toolkit/loader.js -> resource://devtools/server/actors/webconsole.js:842:20\nDSC_onPacket@resource://gre/modules/commonjs/toolkit/loader.js -> resource://devtools/server/main.js:1643:15\nLocalDebuggerTransport.prototype.send/<@resource://gre/modules/commonjs/toolkit/loader.js -> resource://devtools/shared/transport/transport.js:569:11\nexports.makeInfallible/<@resource://gre/modules/commonjs/toolkit/loader.js -> resource://devtools/shared/ThreadSafeDevToolsUtils.js:101:14\nexports.makeInfallible/<@resource://gre/modules/commonjs/toolkit/loader.js -> resource://devtools/shared/ThreadSafeDevToolsUtils.js:101:14\nLine: 1281, column: 16"} Stack: DebuggerClient.prototype.onPacket@resource://gre/modules/commonjs/toolkit/loader.js -> resource://devtools/shared/client/main.js:948:9 LocalDebuggerTransport.prototype.send/<@resource://gre/modules/commonjs/toolkit/loader.js -> resource://devtools/shared/transport/transport.js:569:11 exports.makeInfallible/<@resource://gre/modules/commonjs/toolkit/loader.js -> resource://devtools/shared/ThreadSafeDevToolsUtils.js:101:14 exports.makeInfallible/<@resource://gre/modules/commonjs/toolkit/loader.js -> resource://devtools/shared/ThreadSafeDevToolsUtils.js:101:14 Line: 948, column: 9" Exception captured and raised @ ThreadSafeDevToolsUtils.js:80
So, this reflects some internal disarray in the devtools. Maybe if I explain what the error means, it might help you reproduce the problem! There's a type of object called a Debugger (you say 'new Debugger' to create one) that lets you look into other code and inspect its operation. When you get an object from it, it uses a 'Debugger.Object' instance to represent that object, because content objects can be dangerous for the tools to access directly. If you happen to create two distinct Debugger objects both looking at the same content code, then each one has its own collection of Debugger.Object objects. Using one's with the other is a bug. That's what happened here. So you want to try things like opening, closing, and re-opening the console or the devtools panel, and somehow looking at objects you looked at before, or something else that would somehow connect the first opening with the second. Hope this helps!
Flags: needinfo?(tyfoxteam)
I am only an end user, which means I am totally unfamiliar with the dev tools internals. There is definitely something funky happening behind the scene that shouldn't occur. I've simply posted the browser console stack to give potentially more info on the bug ticket. I was evaluating simple js instructions in the console but wasn't receiving back any form of answer. The stack I posted was displayed in the browser console each time I was evaluating something in the console. Closing/reopening the devtools window (F12) couldn't solve the issue. I had to close the tab then re-open it to get the devtools to behave normally again.
Flags: needinfo?(tyfoxteam)
Sorry, I was unclear. It's definitely a bug in our devtools; you should never see that error. But we need steps to reproduce, in order to debug it. So I gave you a bit of the inside story, hoping it might spark some ideas for how to reproduce the problem. The stack is helpful, but from that alone it's not clear to me how the wrong object could be reaching the `executeInGlobalWindowWithBindings` function, which is what's throwing the error.
Steps to reproduce: Debugging an accordion JS library, had a breakpoint in a function that runs on document.ready. Flipped to Console tab: 19:24:50.570 >>> o 19:24:50.577 <<< Object { context: <a.accordion-title>, length: 1, 1 more… } 19:24:55.227 >>> o.data() 19:24:55.229 <<< Object { accordionTarget: "#base" } Then flipped back to debugger tab, selected continue, then flipped back to Console tab: 19:25:25.592 >>> o That was all it took to break the debugger entirely. Even other, valid things no longer work: 19:25:30.677 >>> alert('hi') 19:25:53.697 >>> $('.accordion-title') Each one makes this occur: 19:25:25.601 main.js:1512:0 error occurred while processing 'evaluateJSAsync: TypeError: Debugger.Object belongs to a different Debugger Stack: WCA_evalWithDebugger@resource://gre/modules/commonjs/toolkit/loader.js -> resource://devtools/server/actors/webconsole.js:1282:16 WCA_onEvaluateJS@resource://gre/modules/commonjs/toolkit/loader.js -> resource://devtools/server/actors/webconsole.js:872:20 WCA_onEvaluateJSAsync@resource://gre/modules/commonjs/toolkit/loader.js -> resource://devtools/server/actors/webconsole.js:842:20 DSC_onPacket@resource://gre/modules/commonjs/toolkit/loader.js -> resource://devtools/server/main.js:1643:15 LocalDebuggerTransport.prototype.send/<@resource://gre/modules/commonjs/toolkit/loader.js -> resource://devtools/shared/transport/transport.js:569:11 exports.makeInfallible/<@resource://gre/modules/commonjs/toolkit/loader.js -> resource://devtools/shared/ThreadSafeDevToolsUtils.js:101:14 exports.makeInfallible/<@resource://gre/modules/commonjs/toolkit/loader.js -> resource://devtools/shared/ThreadSafeDevToolsUtils.js:101:14 Line: 1282, column: 16 DSC__unknownError() main.js:1512 DSC_onPacket() main.js:1645 LocalDebuggerTransport.prototype.send/<() transport.js:569 exports.makeInfallible/<() ThreadSafeDevToolsUtils.js:101 exports.makeInfallible/<() ThreadSafeDevToolsUtils.js:101 I can provide HTML and JS test cases if necessary.
Needinfo'ing myself to check this out tomorrow.
Flags: needinfo?(jimb)
I'm not able to reproduce this in Nightly Firefox. I set a breakpoint in a function, hit the breakpoint, printed a global variable in the console, continued in the debugger, and printed the same global variable in the console; all worked well. Could you provide HTML and JS test cases? Also, could you see if this reproduces in Nightly?
Flags: needinfo?(jimb) → needinfo?(AWilcox)
There was a similar looking error (Bug 1254613) that was resolved probably by Bug 1299602 which landed in 51, so nightly.
No reply to needinfo for a week, and we suspect it's fixed, so closing this bug. Andrew, if you can still reproduce it in a nightly build of Firefox, we're still interested in the specific steps to reproduce; please don't hesitate to reopen the bug.
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → DUPLICATE
Product: Firefox → DevTools
You need to log in before you can comment on or make changes to this bug.