Unexpected "query object's 'source' property is not undefined nor a Debugger.Source object" error during debugger request

RESOLVED FIXED in Firefox 67

Status

defect
P1
normal
RESOLVED FIXED
4 months ago
4 months ago

People

(Reporter: loganfsmyth, Assigned: bhackett)

Tracking

Trunk
Firefox 68
Dependency tree / graph

Firefox Tracking Flags

(firefox67 fixed, firefox68 fixed)

Details

Attachments

(2 attachments)

console.error: "Error while calling actor 'source's method 'getBreakpointPositionsCompressed'" "query object's 'source' property is not undefined nor a Debugger.Source object"
console.error: "_findDebuggeeScripts@resource://devtools/server/actors/source.js:170:21\ngetBreakpointPositions@resource://devtools/server/actors/source.js:309:22\ngetBreakpointPositionsCompressed@resource://devtools/server/actors/source.js:341:24\nhandler@resource://devtools/shared/protocol.js:1189:37\nonPacket@resource://devtools/server/main.js:1291:58\nreceiveMessage@resource://devtools/shared/transport/child-transport.js:66:16\nMessageListener.receiveMessage*_addListener@resource://devtools/shared/transport/child-transport.js:40:14\nready@resource://devtools/shared/transport/child-transport.js:57:10\n_onConnection@resource://devtools/server/main.js:880:15\nconnectToParent@resource://devtools/server/main.js:296:17\nonConnect<@resource://devtools/server/startup/frame.js:59:35\nexports.makeInfallible/<@resource://devtools/shared/ThreadSafeDevToolsUtils.js:109:22\nMessageListener.receiveMessage*@resource://devtools/server/startup/frame.js:80:5\n@resource://devtools/server/startup/frame.js:160:5\n"

This is an error we'd never expect to happen. Currently triggers in one specific case I found, so I'll dig a bit more.

This was originally found by Jason in the test logs for the error

A promise chain failed to handle a rejection: Debugger.Source belongs to a different Debugger - stack: setBreakpointPositions/<@resource://devtools/client/debugger/new/src/actions/breakpoints/breakpointPositions.js:119:3
async*thunk/</</<@resource://devtools/client/debugger/new/src/actions/utils/middleware/thunk.js:21:45
dispatch@resource://devtools/client/shared/vendor/redux.js:755:18
loadSourceTextPromise@resource://devtools/client/debugger/new/src/actions/sources/loadSourceText.js:91:5
async*loadSourceText/</promise<@resource://devtools/client/debugger/new/src/actions/sources/loadSourceText.js:117:24
loadSourceText/<@resource://devtools/client/debugger/new/src/actions/sources/loadSourceText.js:124:9
thunk/</</<@resource://devtools/client/debugger/new/src/actions/utils/middleware/thunk.js:21:45
dispatch@resource://devtools/client/shared/vendor/redux.js:755:18
selectLocation/<@resource://devtools/client/debugger/new/src/actions/sources/select.js:138:11
thunk/</</<@resource://devtools/client/debugger/new/src/actions/utils/middleware/thunk.js:21:45
dispatch@resource://devtools/client/shared/vendor/redux.js:755:18
selectSource/<@resource://devtools/client/debugger/new/src/actions/sources/select.js:94:12
thunk/</</<@resource://devtools/client/debugger/new/src/actions/utils/middleware/thunk.js:21:45
bindActionCreator/<@resource://devtools/client/shared/vendor/redux.js:644:12
selectSource@resource://devtools/client/debugger/new/panel.js:141:26
exports.viewSourceInDebugger@resource://devtools/client/shared/view-source.js:60:17
async*viewSourceInDebugger@resource://devtools/client/framework/toolbox.js:3193:23
_debugClicked@resource://devtools/client/shared/widgets/tooltip/EventTooltipHelper.js:276:15
_headerClicked@resource://devtools/client/shared/widgets/tooltip/EventTooltipHelper.js:211:12
synthesizeMouseAtPoint@chrome://mochikit/content/tests/SimpleTest/EventUtils.js:471:13
synthesizeMouse@chrome://mochikit/content/tests/SimpleTest/EventUtils.js:405:10
@chrome://mochitests/content/browser/devtools/client/inspector/markup/test/browser_markup_view-source.js:47:14
Async*Tester_execTest/<@chrome://mochikit/content/browser-test.js:1106:34
Tester_execTest@chrome://mochikit/content/browser-test.js:1134:12
nextTest/<@chrome://mochikit/content/browser-test.js:995:14
SimpleTest.waitForFocus/waitForFocusInner/focusedOrLoaded/<@chrome://mochikit/content/tests/SimpleTest/SimpleTest.js:803:59

Both of these failures are the same more source, though I don't totally understand what is introducing the difference.

Debugger.Source belongs to a different Debugger

is the core error.

query object's 'source' property is not undefined nor a Debugger.Source object

Is actually happening because source is a Proxy wrapping the Debugger.Source object. I have no idea where the proxy is coming from, but either way they are both caused because we are initializing a source actor with a value that isn't right.

The issue is that https://bugzilla.mozilla.org/show_bug.cgi?id=1531826 introduced a call

const actor = this.targetActor.sources.getOrCreateSourceActor(script.source);

but script.source in this context is a Debugger.Source owned by the local dbg object created by devtools/server/actors/inspector/event-collector.js rather than the Debugger instance created by the thread actor itself, thus resulting in Debugger.Source belongs to a different Debugger.

We realistically shouldn't be reaching across that boundary by mixing Debugger.Source objects from multiple debugger instances.

Brian, could you look into alternative approaches to https://bugzilla.mozilla.org/show_bug.cgi?id=1531826 that might avoid this? Maybe we need a utility somewhere to adopt a Debugger.Source into a new Debugger that is debugging the same source, the same way it currently exposes adoptDebuggeeValue?

Flags: needinfo?(bhackett1024)
Assignee: lsmyth → bhackett1024
Priority: -- → P1
Flags: needinfo?(bhackett1024)
Pushed by bhackett@mozilla.com:
https://hg.mozilla.org/integration/mozilla-inbound/rev/4aad26439dcc
Part 1 - Add Debugger.adoptSource(), r=jorendorff.
https://hg.mozilla.org/integration/mozilla-inbound/rev/2ca4f2aa7160
Part 2 - Tolerate sources from any debugger in getOrCreateSourceActor, r=loganfsmyth.

I had to add some extra logic to these parts to avoid wrapping sources which are in the same compartment as the debugger itself.

What's the motivation for not throwing for same-compartment sources?

(In reply to Logan Smyth [:loganfsmyth] from comment #7)

What's the motivation for not throwing for same-compartment sources?

If we see a same-compartment source and can't provide a source actor to the inspector client, it can still use the script URL to view the source in the debugger.

Ah gotcha. Fair enough. Maybe in the future we can add a separate function. What threw me off is the potential for a function called getOrCreate to potentially do neither.

That would be fine, though ultimately I'd like a better understanding of why the debugger is so sensitive to compartment boundaries. It would be nice if this code wasn't necessary at all.

Status: ASSIGNED → RESOLVED
Closed: 4 months ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 68
https://hg.mozilla.org/projects/ash/rev/4aad26439dccf5acb5acc47df1c9146b1c1b2386
Bug 1536618 Part 1 - Add Debugger.adoptSource(), r=jorendorff.

https://hg.mozilla.org/projects/ash/rev/2ca4f2aa716088f906b640964072888891f6e5d3
Bug 1536618 Part 2 - Tolerate sources from any debugger in getOrCreateSourceActor, r=loganfsmyth.
You need to log in before you can comment on or make changes to this bug.