Open Bug 1551277 Opened 3 years ago Updated 1 year ago

Crash in [@ mozilla::ScrollFrameHelper::BuildDisplayList]


(Core :: Web Painting, defect, P4)

Windows 10



Tracking Status
firefox67 --- wontfix
firefox68 --- wontfix


(Reporter: marcia, Unassigned)


(Keywords: crash, regression)

Crash Data

This bug is for crash report bp-22a5c326-b025-43b4-95b1-863a30190513.

Seen while looking at 67b19 crash stats - seems to have increased in that build and sits at #12 overall:

High correlation to a particular CPU: (88.24% in signature vs 01.29% overall) CPU Info = family 23 model 1 stepping 1 [100.0% vs 05.11% if cpu_arch = amd64]

There are some crashes in this signature in 66.0.5, but the most recent beta definitely has more.

Top 10 frames of crashing thread:

0 xul.dll mozilla::ScrollFrameHelper::BuildDisplayList layout/generic/nsGfxScrollFrame.cpp:3716
1 xul.dll nsIFrame::BuildDisplayListForChild layout/generic/nsFrame.cpp:3880
2 xul.dll nsInlineFrame::BuildDisplayList layout/generic/nsInlineFrame.cpp:216
3 xul.dll nsIFrame::BuildDisplayListForChild layout/generic/nsFrame.cpp:3852
4 xul.dll static void DisplayLine layout/generic/nsBlockFrame.cpp:6425
5 xul.dll nsBlockFrame::BuildDisplayList layout/generic/nsBlockFrame.cpp:6516
6 xul.dll nsIFrame::BuildDisplayListForChild layout/generic/nsFrame.cpp:3880
7 xul.dll static void DisplayLine layout/generic/nsBlockFrame.cpp:6425
8 xul.dll nsBlockFrame::BuildDisplayList layout/generic/nsBlockFrame.cpp:6516
9 xul.dll nsIFrame::BuildDisplayListForChild layout/generic/nsFrame.cpp:3852

Adding another signature spotted in the latest 67 beta: It also had a strong correlation to the same CPU: (100.0% in signature vs 01.29% overall) CPU Info = family 23 model 1 stepping 1

Crash Signature: [@ mozilla::ScrollFrameHelper::BuildDisplayList] → [@ mozilla::ScrollFrameHelper::BuildDisplayList] [@ mozilla::ScrollFrameHelper::MaybeAddTopLayerItems]

Looking at the crash line in the top frame:
It seems to be related to running the dtor for the DisplayListClipState::AutoSaveRestore
in that scope?

Or similarly, the nsDisplayListBuilder::AutoCurrentScrollParentIdSetter dtor in this scope:

Is the stack damaged somehow?

Given that we're building display lists here, it seems more like
a Web Painting issue, but feel free to send it back if it's
a Layout issue.

Component: Layout → Web Painting

Here is the list of uplifts that landed after beta 17, I am not seeing anything related to either Web Painting or Layout that could explain this new crasher:

Interestingly, out of the 160 crashes in beta 19 for these 2 signatures, 159 were on the aurora channel (dev edition)

There appears to be a very strong correlation with specific CPUs here, is that one of the known problematic ones?

1 crash only in RC1 and no crash in devedition 68.0b1, so wontfix 67.

Priority: -- → P4

Very low volume crash. This should be a won't fix for 68.

QA Whiteboard: qa-not-actionable
You need to log in before you can comment on or make changes to this bug.