1279993 - ThreadActor can crash the browser (debug build) when attaching to a page with worker

Status: RESOLVED INVALID

(DevTools :: Debugger, defect, P3)

Description

[Jarda Snajdr [:jsnajdr]]

Attachment: Test pages to reproduce the bug

I discovered this when working on bug 1278778, playing with fetch and workers.

Steps to reproduce:
1. The attached ZIP contains a static HTML page, page script and a worker script.
2. Run a static localhost server with these files
3. Set the http://localhost/worker.html page as your home page
4. Build Firefox in debug mode
5. Start Firefox with mach run --devtools
6. The home page will be loaded at the same time as devtools, triggering a race condition.

Result:
The debug build will crash with a MOZ_ASSERT:

Assertion failure: mParentSuspended (Resumed more than once!), at /Users/jsnajdr/src/gecko-dev/dom/workers/WorkerPrivate.cpp:2835
#01: nsGlobalWindow::ResumeTimeouts(bool, bool)[/Users/jsnajdr/src/gecko-dev/obj-x86_64-apple-darwin15.5.0/dist/NightlyDebug.app/Contents/MacOS/XUL +0x11c6fc6]
#02: nsDOMWindowUtils::ResumeTimeouts()[/Users/jsnajdr/src/gecko-dev/obj-x86_64-apple-darwin15.5.0/dist/NightlyDebug.app/Contents/MacOS/XUL +0x1174f30]
#03: NS_InvokeByIndex[/Users/jsnajdr/src/gecko-dev/obj-x86_64-apple-darwin15.5.0/dist/NightlyDebug.app/Contents/MacOS/XUL +0x108a7f]
#04: CallMethodHelper::Call()[/Users/jsnajdr/src/gecko-dev/obj-x86_64-apple-darwin15.5.0/dist/NightlyDebug.app/Contents/MacOS/XUL +0xb4fb06]

The JS stack trace is at the windowUtils.resumeTimeouts call at:
_ctors/webbrowser.js 1802 postNest
_er/actors/script.js 361 EventLoop.prototype.enter
_er/actors/script.js 541 ThreadActor<._pushThreadPause
_er/actors/script.js 656 ThreadActor<.onAttach
_ools/server/main.js 1648 DSC_onPacket
_nsport/transport.js 568 LocalDebuggerTransport.prototype.send/<
_afeDevToolsUtils.js 101 exports.makeInfallible/<
_afeDevToolsUtils.js 101 exports.makeInfallible/<

Why it happened?
- at [1], windowUtils.suspendTimeouts() is called, and a while later, at [2], we call windowUtils.resumeTimeouts().
- one part of the suspend/resume process is suspending/resuming workers at [3] and [4].
- when suspending the workers, the window doesn't yet have any.
- when resuming the workers, one got created in the meantime.
- because the new worker was never suspended, the resume fails an assert at [5].

To trigger the race condition, several things must work together:
- the worker-script.js cannot be inline in the HTML page, must be loaded from a separate file
- cannot just call new Worker("worker-script.js"), we must go through the blob URL
- without this, the crash disappeared and I couldn't reproduce it

[1] https://dxr.mozilla.org/mozilla-central/source/devtools/server/actors/script.js#346
[2] https://dxr.mozilla.org/mozilla-central/source/devtools/server/actors/script.js#361
[3] https://dxr.mozilla.org/mozilla-central/source/dom/base/nsGlobalWindow.cpp#13003
[4] https://dxr.mozilla.org/mozilla-central/source/dom/base/nsGlobalWindow.cpp#13095
[5] https://dxr.mozilla.org/mozilla-central/source/dom/workers/WorkerPrivate.cpp#2833

Comment 1

[Jarda Snajdr [:jsnajdr]]

Note: I can reproduce this reliably only in non-e10s. Not sure if the race condition is in e10s, too.

Comment 2

[Eddy Bruel [:ejpbruel]]

This is a crasher, so I'm marking this as P1.

This looks like a race condition in the worker debugger API, so I'm probably the most qualified person to look into it.

Comment 3

[Emma Humphries ☕️🎸🧞‍♀️✨ (she/they) [:emceeaich] (Pacific Time) use needinfo]

This is a P1 bug without an assignee. 

P1 are bugs which are being worked on for the current release cycle/iteration/sprint. 

If the bug is not assigned by Monday, 28 August, the bug's priority will be reset to '--'.

Comment 4

[BugBot [:suhaib / :marco/ :calixte]]

Moving to p3 because no activity for at least 24 weeks.
See https://github.com/mozilla/bug-handling/blob/master/policy/triage-bugzilla.md#how-do-you-triage for more information

Comment 5

[Jason Laster [:jlast]]

Honza, jarda, could you verify that this still crashes?

Comment 6

[Jan Honza Odvarko [:Honza] (always need-info? me)]

I followed the steps in comment #0 and I can't reproduce the crash on my machine (Win 10, Nightly debug build)

Closing

Honza