Closed Bug 1428765 Opened 2 years ago Closed 2 years ago
Crash in ns
Display Item::Set Clip Chain
Bug 1428765 - Fix scenario where display item clip chains hash to different values even though they are equal.
59 bytes, text/x-review-board-request
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 =============================================================
2 years ago
Priority: -- → P3
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
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  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.  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+
Duplicate of this bug: 1429008
Pushed by email@example.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
You need to log in before you can comment on or make changes to this bug.