2070925 - setDebuggerReady(false) suspends nothing: the DispatchLockHeld hold is unsatisfiable

Status: RESOLVED FIXED

(Core :: DOM: Workers, defect)

Description

[Florian Quèze [:florian]]

nsIWorkerDebugger.setDebuggerReady(false) is documented to prevent all content from running in a worker, so that a debugger which has not finished attaching can hold the worker until it is ready. It holds nothing. The gate in WorkerPrivate::DispatchLockHeld is never taken, so a late attach silently loses whatever ran first.

Bug 1899503 replaced a single condition with a conjunction where a disjunction was intended. !mDebuggerReady && !mRemoteDebuggerReady can never both hold: mDebuggerReady is only cleared through the local WorkerDebugger, which a worker only has when UseRemoteDebugger() is false.

Reactivating a hold that has been dead since bug 1899503 is not risk-free. Nothing in CI exercises it, and the MOZ_RELEASE_ASSERT(!aSyncLoopTarget) inside it goes live again.

Comment 1

[Florian Quèze [:florian]]

Attachment: Bug 2070925 - Make setDebuggerReady(false) suspend the debuggee again, r=#dom-worker-reviewers,edenchuang.

The hold suspended nothing: !mDebuggerReady && !mRemoteDebuggerReady can never
both be true, since the two flags are cleared on mutually exclusive
UseRemoteDebugger() branches. So no debuggee runnable has been queued since
Bug 1899503.

Restoring the hold means the three flush sites drop the mDebuggerRegistered term,
which a remote worker never sets, and which RegisterDebuggerMainThread has
normally already set for a local one.

Comment 2

[BugBot [:suhaib / :marco]]

Set release status flags based on info from the regressing bug 1899503

Comment 3

[Pulsebot]

Pushed by [e-mail]:
https://github.com/mozilla-firefox/firefox/commit/52f64e7e39f8
https://hg.mozilla.org/integration/autoland/rev/abae7abb41ea
Make setDebuggerReady(false) suspend the debuggee again, r=edenchuang,dom-worker-reviewers.

Comment 4

[Sandor Molnar[:smolnar]]

https://hg.mozilla.org/mozilla-central/rev/abae7abb41ea