Crash in nsDisplayItem::SetClipChain

RESOLVED FIXED in Firefox 59

Status

()

defect
P3
critical
RESOLVED FIXED
2 years ago
2 years ago

People

(Reporter: marcia, Assigned: kats)

Tracking

(Blocks 1 bug, {crash, regression})

Trunk
mozilla59
Unspecified
macOS
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox-esr52 unaffected, firefox57 unaffected, firefox58 unaffected, firefox59 fixed)

Details

(crash signature)

Attachments

(1 attachment)

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

Seen while looking at nightly crash stats: http://bit.ly/2D69vGX. Possible regression range based on Build ID: https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=81362f7306fe413b19fdba27cd0e9a5525d902e1&tochange=36aaa86e37bac0db15a499a7f48a83bf9dff5602

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)
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.

[1] https://searchfox.org/mozilla-central/rev/cf149b7b63ff97023e28723167725e38cf5df757/layout/painting/nsDisplayList.cpp#1600
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.

https://reviewboard.mozilla.org/r/211420/#review217216

Yikes. Not the kind of bug you'd foresee by reading the code...
Attachment #8941155 - Flags: review?(mstange) → review+
Pushed by kgupta@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/865837f77a90
Fix scenario where display item clip chains hash to different values even though they are equal. r=mstange
https://hg.mozilla.org/mozilla-central/rev/865837f77a90
Status: NEW → RESOLVED
Closed: 2 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla59
You need to log in before you can comment on or make changes to this bug.