1919178 - Crash in [@ mozilla::nsDisplayListBuilder::GetBuildingExtraPagesForPageNum]

Status: RESOLVED WORKSFORME

(Core :: Web Painting, defect)

Description

[BugBot [:suhaib / :marco]]

Crash report: https://crash-stats.mozilla.org/report/index/95c4899d-9e67-46f3-8a83-43fe10240915

Reason: EXCEPTION_ACCESS_VIOLATION_READ

Top 10 frames of crashing thread:

0  xul.dll  mozilla::nsDisplayListBuilder::GetBuildingExtraPagesForPageNum const  layout/painting/nsDisplayList.h:1553
0  xul.dll  mozilla::MakeDisplayItemWithIndex  layout/painting/nsDisplayList.h:1971
0  xul.dll  mozilla::MakeDisplayItem  layout/painting/nsDisplayList.h:2010
0  xul.dll  WrapInWrapList  layout/generic/nsIFrame.cpp:3901
0  xul.dll  nsIFrame::BuildDisplayListForChild  layout/generic/nsIFrame.cpp:4360
1  xul.dll  nsFlexContainerFrame::BuildDisplayList  layout/generic/nsFlexContainerFrame.cpp:2945
1  xul.dll  nsIFrame::BuildDisplayListForChild  layout/generic/nsIFrame.cpp:4339
2  xul.dll  nsFlexContainerFrame::BuildDisplayList  layout/generic/nsFlexContainerFrame.cpp:2945
3  xul.dll  nsIFrame::BuildDisplayListForSimpleChild  layout/generic/nsIFrame.cpp:4009
3  xul.dll  nsIFrame::BuildDisplayListForChild  layout/generic/nsIFrame.cpp:4113

By querying Nightly crashes reported within the last 2 months, here are some insights about the signature:

• First crash report: 2024-08-13
• Process type: Multiple distinct types
• Is startup crash: No
• Has user comments: No
• Is null crash: Yes - 2 out of 3 crashes happened on null or near null memory address

Comment 1

[Daniel Holbert [:dholbert]]

60% of the crash volume here over the past 6 months has CPU Info: family 6 model 183 stepping 1, which is the same arch as in bug 1898999 comment 7 (and other bugs) which has known CPU issues. This includes the crash linked in comment 0 here.

So I think we can consider this stalled and largely or entirely explainable by bad hardware. (The crash doesn't really make sense; we're crashing in a trivial getter on a nsDisplayListBuilder instance that we just called several other methods on, so there's no reason it should be nullptr. So: smells like gremlins / bad hardware.)

Also, I'm reclassifying to Web Painting -- the innermost function here happens to be checking whether or not we're printing, I think, but it (and the backtrace) are all display-list code, and I'm not seeing any suggestions from the backtrace that we are actually printing.

Comment 2

[BugBot [:suhaib / :marco]]

Closing because no crashes reported for 12 weeks.

Comment 3

[BugBot (nomail) [:suhaib / :marco/ :calixte]]

Since the bug is closed, the stalled keyword is now meaningless.
For more information, please visit BugBot documentation.