Closed Bug 1428765 Opened 5 years ago Closed 5 years ago

Crash in nsDisplayItem::SetClipChain


(Core :: Graphics: WebRender, defect, P3)




Tracking Status
firefox-esr52 --- unaffected
firefox57 --- unaffected
firefox58 --- unaffected
firefox59 --- fixed


(Reporter: marcia, Assigned: kats)



(Keywords: crash, regression)

Crash Data


(1 file)

This bug was filed from the Socorro interface and is
report bp-1da823db-3ca7-48a6-8a75-b57360180107.

Seen while looking at nightly crash stats: Possible regression range based on Build ID:

Possibly Bug 1422057? ni on :kats

Top 10 frames of crashing thread:

0 XUL nsDisplayItem::SetClipChain layout/painting/nsDisplayList.h:334
1 XUL nsDisplayItem::nsDisplayItem layout/painting/nsDisplayList.cpp:2974
2 XUL nsDisplayBackgroundImage::nsDisplayBackgroundImage layout/painting/nsDisplayList.cpp:2945
3 XUL nsDisplayBackgroundImage::AppendBackgroundItemsToTop layout/painting/nsDisplayList.cpp:3428
4 XUL nsFrame::DisplayBorderBackgroundOutline layout/generic/nsFrame.cpp:2319
5 XUL nsBlockFrame::BuildDisplayList layout/generic/nsBlockFrame.cpp:6687
6 XUL nsIFrame::BuildDisplayListForChild layout/generic/nsFrame.cpp:3782
7 XUL DisplayLine layout/generic/nsBlockFrame.cpp:6650
8 XUL nsBlockFrame::BuildDisplayList layout/generic/nsBlockFrame.cpp:6745
9 XUL nsIFrame::BuildDisplayListForChild layout/generic/nsFrame.cpp:3782

Flags: needinfo?(bugmail)
Duplicate of this bug: 1428770
Not really sure offhand why this is happening. But I agree it's probably introduced by my patches so I'll take a look.
Assignee: nobody → bugmail
Flags: needinfo?(bugmail)
I've had this crash fairly regularly today, if there's anything you think I can do to help isolate or provide STR let me know!
If you have STR that would be great!
It seems as if Bug 1429008 has one possible way to reproduce the crash.
I got a URL from Stuart yesterday that lets me reproduce as well. I'm debugging but it's slow going since it only happens on OS X and I can't use rr there.
Adding another crash signature which falls within the same regression range and is 10.13 only.
Crash Signature: [@ nsDisplayItem::SetClipChain] → [@ nsDisplayItem::SetClipChain] [@ mozilla::DisplayListClipState::InvalidateCurrentCombinedClipChain]
This is really bizarre. What seems to be happening is that sometimes the unordered_set::insert(c) call at [1] is returning (c, false). That means we go ahead and destroy c, and then return that very same pointer. This garbage return value is what later causes the crash.

I added some more logging and it looks like in a small number of cases, the unordered_set::insert(x) is returning (y, false) even though a call to unordered_set::find(x) just prior to it doesn't find anything. As long as x != y we don't crash, even though this seems like it violates the unordered_set API.

One possibility is that the custom hash/equals functions I'm providing to the unordered_set are buggy, so I'm going to check that. If those are fine, then the only possibility I can see is that this is a bug in the implementation of unordered_set itself. That might explain why it only happens on OS X.

Yeah this is my fault. The hash function sometimes returns different values for two DisplayItemClipChain items that are ::Equal.
Comment on attachment 8941155 [details]
Bug 1428765 - Fix scenario where display item clip chains hash to different values even though they are equal.

Yikes. Not the kind of bug you'd foresee by reading the code...
Attachment #8941155 - Flags: review?(mstange) → review+
Duplicate of this bug: 1429008
Pushed by
Fix scenario where display item clip chains hash to different values even though they are equal. r=mstange
Closed: 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla59
You need to log in before you can comment on or make changes to this bug.