Closed Bug 1646330 Opened 2 years ago Closed 2 years ago

Crash in [@ mozilla::SharedStyleSheetCache::InsertIntoCompleteCacheIfNeeded]


(Core :: CSS Parsing and Computation, defect)

79 Branch
Windows 10



83 Branch
Tracking Status
firefox-esr68 --- unaffected
firefox-esr78 --- unaffected
firefox77 --- unaffected
firefox78 --- unaffected
firefox79 --- wontfix
firefox80 --- wontfix
firefox81 --- wontfix
firefox82 --- wontfix
firefox83 --- fixed


(Reporter: calixte, Assigned: emilio)


(Blocks 1 open bug, Regression)


(4 keywords)

Crash Data


(1 file)

This bug is for crash report bp-2f5c6786-7faf-40de-8f8d-43ea20200616.

Top 10 frames of crashing thread:

0 xul.dll mozilla::SharedStyleSheetCache::InsertIntoCompleteCacheIfNeeded layout/style/SharedStyleSheetCache.cpp:397
1 xul.dll static mozilla::SharedStyleSheetCache::LoadCompletedInternal layout/style/SharedStyleSheetCache.cpp:327
2 xul.dll static mozilla::SharedStyleSheetCache::LoadCompleted layout/style/SharedStyleSheetCache.cpp:263
3 xul.dll mozilla::MozPromise<bool, bool, 1>::ThenValue<`lambda at /builds/worker/checkouts/gecko/layout/style/Loader.cpp:1424:11', `lambda at /builds/worker/checkouts/gecko/layout/style/Loader.cpp:1429:11'>::DoResolveOrRejectInternal xpcom/threads/MozPromise.h:769
4 xul.dll mozilla::MozPromise<bool, bool, 1>::ThenValueBase::ResolveOrRejectRunnable::Run xpcom/threads/MozPromise.h:410
5 xul.dll mozilla::SchedulerGroup::Runnable::Run xpcom/threads/SchedulerGroup.cpp:146
6 xul.dll nsThread::ProcessNextEvent xpcom/threads/nsThread.cpp:1234
7 xul.dll NS_ProcessNextEvent xpcom/threads/nsThreadUtils.cpp:501
8 xul.dll mozilla::ipc::MessagePump::Run ipc/glue/MessagePump.cpp:87
9 xul.dll MessageLoop::RunHandler ipc/chromium/src/base/

There are 5 crashes (from 5 installations) in nightly 79 starting with buildid 20200615214838. In analyzing the backtrace, the regression may have been introduced by patch [1] to fix bug 1599160.


Flags: needinfo?(emilio)

Hmm, there are a couple of URLs, but I haven't reproduced the issue in any of them... Jason, do you know if any fuzzer has hit this yet?

Flags: needinfo?(jkratzer)

(In reply to Emilio Cobos Álvarez (:emilio) from comment #1)

Hmm, there are a couple of URLs, but I haven't reproduced the issue in any of them... Jason, do you know if any fuzzer has hit this yet?

No, unfortunately not. I'll keep an eye out for this bug if it comes in.

Flags: needinfo?(jkratzer)

S3 for now, since it's very low crash volume so far. But it's due to the code in question hasn't reached to betas/releases. (that said, Jason and Emilo keep eyes on this, so hopefully this will be fixed before the next beta)

Severity: -- → S3

This is a diagnostic assert, so won't cause any badness in release. Given that and the low volume I think I won't spend a lot of time on it without a test-case or STR. Though I am curious about what could cause this.

Flags: needinfo?(emilio)
Duplicate of this bug: 1649506
Crash Signature: [@ mozilla::SharedStyleSheetCache::InsertIntoCompleteCacheIfNeeded] → [@ mozilla::SharedStyleSheetCache::InsertIntoCompleteCacheIfNeeded] [@ mozilla::SharedStyleSheetCache::LoadCompletedInternal]
Crash Signature: [@ mozilla::SharedStyleSheetCache::InsertIntoCompleteCacheIfNeeded] [@ mozilla::SharedStyleSheetCache::LoadCompletedInternal] → [@ mozilla::SharedStyleSheetCache::InsertIntoCompleteCacheIfNeeded] [@ mozilla::SharedStyleSheetCache::LoadCompletedInternal]

Wouldn't domino or any of the other fuzzers have hit this by any chance right?

Flags: needinfo?(jkratzer)

No, unfortunately not. We have solid coverage of the code in question but I don't have a record of any crash matching that signature.

Flags: needinfo?(jkratzer)

I experienced this bug yesterday when I was looking at the pre-order of the PS5 (I am not saying that to make Jason happy :)

Bumping up severity based on volume.

Severity: S3 → S2

My two guesses about how this can happen are:

  • PR_Now() is not guaranteed to be monotonic. We can hit an expired
    entry and in-flight become "unexpired".

  • nsLoadGroup flags being mutated mid-load (by stuff like devtools).

I tried to reproduce this in both ways but I couldn't, but it doesn't
seem far-fetched.

In any case this failing this assert is not a correctness issue (this
branch is intended to catch cases where we do too much work, but the
consequence of it being violated is just we have performed an extra
load), so let's not crash nightly / early-beta users as we don't have
any way to reproduce it.

Assignee: nobody → emilio

If we happen to have a repro now I'd be extremely interested anyhow :-)

Flags: needinfo?(jkratzer)

No, sorry - still nothing from the fuzzers.

Flags: needinfo?(jkratzer)
Pushed by
Downgrade an assertion to a regular MOZ_ASSERT. r=jwatt
Closed: 2 years ago
Resolution: --- → FIXED
Target Milestone: --- → 83 Branch
Has Regression Range: --- → yes
You need to log in before you can comment on or make changes to this bug.