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

Status: RESOLVED DUPLICATE of bug 1299602

(DevTools :: Debugger, defect)

Comment 1

[April King [:April]]

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.

Comment 2

[April King [:April]]

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 }

Comment 3

[Geoffrey D.]

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

Comment 4

[Jim Blandy :jimb]

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!

Comment 5

[Geoffrey D.]

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.

Comment 6

[Jim Blandy :jimb]

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.

Comment 7

[A. Wilcox [:awilfox]]

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.

Comment 8

[Jim Blandy :jimb]

Needinfo'ing myself to check this out tomorrow.

Comment 9

[Jim Blandy :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?

Comment 10

[Brian Grinstead [:bgrins]]

There was a similar looking error (Bug 1254613) that was resolved probably by Bug 1299602 which landed in 51, so nightly.

Comment 11

[Jim Blandy :jimb]

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.