1274733 - intermittent PROCESS-CRASH | dom/workers/test/serviceworkers/test_sanitize_domain.html | application crashed [@ ScriptLoaderRunnable::LoadingFinished] from Assertion failure: !loadInfo.mLoadingFinished, at ScriptLoader.cpp:605

Status: RESOLVED WORKSFORME

(Core :: DOM: Workers, defect, P5)

Description

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

New intermittent failure:

Assertion failure: !loadInfo.mLoadingFinished, at /home/worker/workspace/build/src/dom/workers/ScriptLoader.cpp:605
TEST-UNEXPECTED-TIMEOUT | dom/workers/test/serviceworkers/test_sanitize_domain.html | application timed out after 330 seconds with no output
TEST-UNEXPECTED-FAIL | dom/workers/test/serviceworkers/test_sanitize_domain.html | application terminated with exit code 6
PROCESS-CRASH | dom/workers/test/serviceworkers/test_sanitize_domain.html | application crashed [@ ScriptLoaderRunnable::LoadingFinished]
PROCESS-CRASH | dom/workers/test/serviceworkers/test_sanitize_domain.html | application crashed [@ libc-2.15.so + 0xe79d3]
TEST-UNEXPECTED-FAIL | leakcheck | tab process: missing output line for total leaks!
TEST-UNEXPECTED-FAIL | leakcheck | default process: missing output line for total leaks! 

on this build:

https://treeherder.mozilla.org/logviewer.html#?job_id=28341757&repo=mozilla-inbound

which I suspect is a regression from:
https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?changeset=bc6334aea116

Comment 1

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

(though it could also just be coincidence)

Comment 2

[Boris Zbarsky [:bzbarsky]]

Hmm.  It's possible in theory I guess, but not that likely; I didn't touch any code that would directly involve the worker scriptloader.  

If we're hitting this assert and it's legit (as opposed to being a bitflip in RAM or something), one of three things happened, I think:

1)  Necko called us twice for OnStreamComplete.  Seems moderately unlikely.
2)  We assigned the same index to two different ScriptLoaderRunnable instances,
    so they poked the same ScriptLoadInfo.
3)  We landed in CancelMainThread and didn't have a loadInfo.mChannel to cancel, but
    our OnStreamComplete still got called after that.  Still seems unlikely, actually;
    the only place we explicitly null out mChannel is in OnStreamCompleteInternal there.

I can try to reproduce this in rr if it's happened more than once.....

Comment 3

[BMO Automation]

Bulk assigning P3 to all open intermittent bugs without a priority set in Firefox components per bug 1298978.

Comment 4

[Jens Stutte [:jstutte]]

We do not see this any more.