568487 - Firefox Crash @ nsIFrame::BuildDisplayListForChild

Status: NEW

(Core :: Web Painting, defect)

Description

[chris hofmann]

this crash has been around for awhile at about 275 crashes per day

found in: 3.6.3 3.5.9 3.0.19 3.6 3.6.4 3.7a4 3.6.2 3.5 3.6b4 3.6b1 3.5.8 3.5.7 3.5.5 3.5.4 3.0b5 3.0b3 3.0.8 3.0.15 3.0

most frequently on xp and mac 10.4

Win5.1  0.79
Win6.0  0.03
Win6.1  0.06
Mac10.4 0.11
Mac10.5 0.00
Mac10.6 0.00
Lin2.4  0.00


there are a variety of forms of the stack with this one being the most frequent.

          41 nsIFrame::BuildDisplayListForChild(nsDisplayListBuilder *,nsIFrame *,nsRect const &,nsDisplayListSet const &,unsigned int)
        DisplayLine
        nsBlockFrame::BuildDisplayList(nsDisplayListBuilder *,nsRect const &,nsDisplayListSet const &)
        nsIFrame::BuildDisplayListForChild(nsDisplayListBuilder *,nsIFrame *,nsRect const &,nsDisplayListSet const &,unsigned int)
        DisplayLine
        nsBlockFrame::BuildDisplayList(nsDisplayListBuilder *,nsRect const &,nsDisplayListSet const &)
        nsIFrame::BuildDisplayListForChild(nsDisplayListBuilder *,nsIFrame *,nsRect const &,nsDisplayListSet const &,unsigned int)
        DisplayLine

url's reflect general browsing

domains of sites
  30 http://www.facebook.com
  30 \N//
  12 http://www.orkut.com.br
  11 http://www.youtube.com
   9 //
   3 https://mail.google.com
   3 http://www.4shared.com
   3 http://vkontakte.ru
   3 http://tv.repubblica.it
   3 http://apps.facebook.com
   2 http://www.yamahaskola.cz
   2 http://www.keezmovies.com
   2 http://www.hulu.com
   2 http://www.ebay.de
   2 http://us.mg4.mail.yahoo.com
   2 about:blank//
   1 wyciwyg://3
   1 wyciwyg://2
   1 wyciwyg://0
<long tail snipped>

I'll post a breakdown of all the stacks and maybe the becomes a tracking bug for several that we need to spin off.

Comment 1

[chris hofmann]

Attachment: breakdown of nsiframebuilder stacks from 2010 05 26

Comment 2

[chris hofmann]

more reports at  http://crash-stats.mozilla.com/report/list?product=Firefox&query_search=signature&query_type=exact&query=nsIFrame%3A%3ABuildDisplayListForChild%28nsDisplayListBuilder*%2C%20nsIFrame*%2C%20nsRect%20const%26%2C%20nsDisplayListSet%20const%26%2C%20unsigned%20int%29&date=05%2F27%2F2010%2006%3A35%3A42&range_value=1&range_unit=weeks&hang_type=any&process_type=any&plugin_field=&plugin_query_type=&plugin_query=&do_query=1&signature=nsIFrame%3A%3ABuildDisplayListForChild%28nsDisplayListBuilder*%2C%20nsIFrame*%2C%20nsRect%20const%26%2C%20nsDisplayListSet%20const%26%2C%20unsigned%20int%29

Comment 3

[chris hofmann]

> 
> there are a variety of forms of the stack with this one being the most
> frequent.
> 
>           41 nsIFrame::BuildDisplayListForChild(nsDisplayListBuilder *,nsIFrame
> *,nsRect const &,nsDisplayListSet const &,unsigned int)
>         DisplayLine
>         nsBlockFrame::BuildDisplayList(nsDisplayListBuilder *,nsRect const
> &,nsDisplayListSet const &)
>         nsIFrame::BuildDisplayListForChild(nsDisplayListBuilder *,nsIFrame
> *,nsRect const &,nsDisplayListSet const &,unsigned int)
>         DisplayLine
>         nsBlockFrame::BuildDisplayList(nsDisplayListBuilder *,nsRect const
> &,nsDisplayListSet const &)
>         nsIFrame::BuildDisplayListForChild(nsDisplayListBuilder *,nsIFrame
> *,nsRect const &,nsDisplayListSet const &,unsigned int)
>         DisplayLine
> 

here is a full report for this form of the stack

http://crash-stats.mozilla.com/report/index/bc16c8f7-66c5-4d1f-b326-3608a2100526

Comment 4

[chris hofmann]

here is a report for the second most frequent sequence in the top 8 frames

http://crash-stats.mozilla.com/report/index/b650276a-5d0a-4e67-ba5f-3d5c92100526

  13 nsIFrame::BuildDisplayListForChild(nsDisplayListBuilder *,nsIFrame *,nsRect const &,nsDisplayListSet const &,unsigned int)
	nsContainerFrame::BuildDisplayListForNonBlockChildren(nsDisplayListBuilder *,nsRect const &,nsDisplayListSet const &,unsigned int)
	nsHTMLContainerFrame::DisplayTextDecorationsAndChildren(nsDisplayListBuilder *,nsRect const &,nsDisplayListSet const &)
	nsInlineFrame::BuildDisplayList(nsDisplayListBuilder *,nsRect const &,nsDisplayListSet const &)
	nsIFrame::BuildDisplayListForChild(nsDisplayListBuilder *,nsIFrame *,nsRect const &,nsDisplayListSet const &,unsigned int)
	DisplayLine
	nsBlockFrame::BuildDisplayList(nsDisplayListBuilder *,nsRect const &,nsDisplayListSet const &)
	nsIFrame::BuildDisplayListForChild(nsDisplayListBuilder *,nsIFrame *,nsRect const &,nsDisplayListSet const &,unsigned int)

Comment 5

[Scoobidiver (away)]

It is #50 top crasher in b7pre for the last week.

Signature	nsIFrame::BuildDisplayListForChild(nsDisplayListBuilder*, nsIFrame*, nsRect const&, nsDisplayListSet const&, unsigned int)
UUID	dba5e01a-40fa-4b9b-922f-e3fca2101002
Time 	2010-10-02 05:57:41.844840
Uptime	209
Last Crash	43555 seconds (12.1 hours) before submission
Install Age	209 seconds (3.5 minutes) since version was first installed.
Product	Firefox
Version	4.0b7pre
Build ID	20101001082844
Branch	2.0
OS	Windows NT
OS Version	6.1.7600
CPU	x86
CPU Info	GenuineIntel family 15 model 4 stepping 9
Crash Reason	EXCEPTION_ACCESS_VIOLATION_READ
Crash Address	0x4
App Notes 	AdapterVendorID: 1106, AdapterDeviceID: 3344

Frame 	Module 	Signature [Expand] 	Source
0 	xul.dll 	nsIFrame::BuildDisplayListForChild 	layout/generic/nsFrame.cpp:1634
1 	xul.dll 	DisplayRows 	layout/tables/nsTableRowGroupFrame.cpp:229
2 	xul.dll 	nsTableFrame::DisplayGenericTablePart 	layout/tables/nsTableFrame.cpp:1242
3 	xul.dll 	nsTableRowGroupFrame::BuildDisplayList 	layout/tables/nsTableRowGroupFrame.cpp:271
4 	xul.dll 	nsIFrame::BuildDisplayListForChild 	layout/generic/nsFrame.cpp:1691
5 	xul.dll 	nsTableFrame::GenericTraversal 	layout/tables/nsTableFrame.cpp:1182
6 	xul.dll 	nsTableFrame::DisplayGenericTablePart 	layout/tables/nsTableFrame.cpp:1242
7 	xul.dll 	nsTableFrame::BuildDisplayList 	layout/tables/nsTableFrame.cpp:1330
...
50 	xul.dll 	nsIFrame::BuildDisplayListForStackingContext 	layout/generic/nsFrame.cpp:1440
51 	xul.dll 	nsLayoutUtils::GetFramesForArea 	layout/base/nsLayoutUtils.cpp:1104
52 	xul.dll 	nsLayoutUtils::GetFrameForPoint 	layout/base/nsLayoutUtils.cpp:1074
53 	xul.dll 	PresShell::HandleEvent 	layout/base/nsPresShell.cpp:6565
54 	xul.dll 	nsViewManager::DispatchEvent 	view/src/nsViewManager.cpp:1071
55 	xul.dll 	AttachedHandleEvent 	view/src/nsView.cpp:193
56 	xul.dll 	nsWindow::DispatchEvent 	widget/src/windows/nsWindow.cpp:3554
57 	xul.dll 	nsWindow::DispatchWindowEvent 	widget/src/windows/nsWindow.cpp:3577
58 	xul.dll 	nsWindow::DispatchMouseEvent 	widget/src/windows/nsWindow.cpp:4000
59 	xul.dll 	nsWindow::ClientMarginHitTestPoint 	widget/src/windows/nsWindow.cpp:5630
60 	xul.dll 	xul.dll@0x46d5d5 	
61 	xul.dll 	nsWindow::WindowProcInternal 	widget/src/windows/nsWindow.cpp:4353
62 	xul.dll 	nsWindow::WindowProc 	widget/src/windows/nsWindow.cpp:4305

More reports at:
http://crash-stats.mozilla.com/report/list?range_value=4&range_unit=weeks&signature=nsIFrame%3A%3ABuildDisplayListForChild%28nsDisplayListBuilder*%2C%20nsIFrame*%2C%20nsRect%20const%26%2C%20nsDisplayListSet%20const%26%2C%20unsigned%20int%29&version=Firefox%3A4.0b7pre

Comment 6

[David Baron :dbaron: (⌚️UTC-5, no longer working on Mozilla)]

I don't think a crash at #50 is a blocker if we don't have steps to reproduce; I'd rather devote crash-fixing efforts to higher crashes or to crashes where we can repro.

Comment 7

[Scoobidiver (away)]

It is #37 top crasher in 4.0b10.

Comment 10

[Scoobidiver (away)]

It's "only" #68 top browser crasher in 9.0.1.
But it's #20 top browser crasher in 10.0b4, #22 in 11.0a2 and #37 in 12.0a1.

Now the stack looks like:
Frame 	Module 	Signature [Expand] 	Source
0 	xul.dll 	nsIFrame::BuildDisplayListForChild 	layout/generic/nsFrame.cpp:1962
1 	xul.dll 	nsBoxFrame::BuildDisplayList 	layout/xul/base/src/nsBoxFrame.cpp:1332
2 	xul.dll 	nsIFrame::BuildDisplayListForChild 	layout/generic/nsFrame.cpp:1995
3 	xul.dll 	nsBoxFrame::BuildDisplayList 	layout/xul/base/src/nsBoxFrame.cpp:1332
4 	xul.dll 	nsIFrame::BuildDisplayListForChild 	layout/generic/nsFrame.cpp:1995
5 	xul.dll 	nsBoxFrame::BuildDisplayList 	layout/xul/base/src/nsBoxFrame.cpp:1332
6 	xul.dll 	nsIFrame::BuildDisplayListForChild 	layout/generic/nsFrame.cpp:2038
7 	xul.dll 	nsBoxFrame::BuildDisplayList 	layout/xul/base/src/nsBoxFrame.cpp:1332
and so on

More reports at:
https://crash-stats.mozilla.com/report/list?signature=nsIFrame%3A%3ABuildDisplayListForChild%28nsDisplayListBuilder*%2C+nsIFrame*%2C+nsRect+const%26%2C+nsDisplayListSet+const%26%2C+unsigned+int%29
https://crash-stats.mozilla.com/report/list?signature=nsIFrame%3A%3ABuildDisplayListForChild

Please don't exclude it from the desktop top crasher list because it has a mobile keyword. See http://bit.ly/vO7SxB.

Comment 11

[Alex Keybl [:akeybl]]

roc - can you find an assignee for this issue? We're making sure that every tracked issue (including top crashers) have an assignee.

Please let us know how QA and the crash-kill help in the investigation. We should try to figure out next steps.

Comment 12

[Timothy Nikkel (:tnikkel)]

I've seen this crash in crash stats for a long time now, but the stacks never provide me anything useful to go on. The stacks are normal, but we crash in a weird place. Maybe something is stepping on our memory? Can we look at correlations with addons or plugins or drivers or anything? I'm not really sure where to go with this.

Comment 13

[Timothy Nikkel (:tnikkel)]

Being able to reproduce somewhere would obviously help.

Comment 14

[Timothy Nikkel (:tnikkel)]

Did this spike in frequency? If so changesets that might have caused a spike might be useful.

Comment 15

[Scoobidiver (away)]

(In reply to Timothy Nikkel (:tn) from comment #12)
> Can we look at correlations with addons or plugins or drivers or anything?
EXCEPTION_ILLEGAL_INSTRUCTION crashes are correlated to ATI/AMD drivers:
  nsIFrame::BuildDisplayListForChild(nsDisplayListBuilder*, nsIFrame*, nsRect const&, nsDisplayListSet const&, unsigned int)|EXCEPTION_ILLEGAL_INSTRUCTION (165 crashes)
     95% (156/165) vs.   6% (3150/54820) atidxx32.dll
         72% (118/165) vs.   1% (352/54820) 8.17.10.318
          5% (9/165) vs.   0% (106/54820) 8.17.10.325
          7% (11/165) vs.   0% (141/54820) 8.17.10.331
          2% (3/165) vs.   0% (160/54820) 8.17.10.337
          4% (7/165) vs.   0% (213/54820) 8.17.10.355
          1% (2/165) vs.   1% (383/54820) 8.17.10.362
          1% (1/165) vs.   0% (112/54820) 8.17.10.378
          1% (2/165) vs.   0% (243/54820) 8.17.10.405
          2% (3/165) vs.   1% (532/54820) 8.17.10.414
I filed bug 728533 for that.

There are no clear correlations for EXCEPTION_ACCESS_VIOLATION_READ crashes.

Note: this crash doesn't appear in the desktop top crashers because it has the mobile-crash whiteboard (see https://wiki.mozilla.org/Platform/2012-02-14#Desktop).

Comment 16

[Sheila Mooney]

Is this a candidate for the blocklist? Is there some specific fix in mind?

Comment 17

[Timothy Nikkel (:tnikkel)]

Best theory so far is that AMD/ATI are causing this to increase (bug 728533) (although doesn't seem responsible for all crashes). Blocklisting those drivers is bug 722538.

Comment 18

[Alex Keybl [:akeybl]]

The blocklist should have gone live yesterday - we'll follow up with Jorge and Sheila to make sure it's enabled for all beta users and to find out whether or not it's lowering the crash numbers here.

Comment 19

[Alex Keybl [:akeybl]]

(In reply to Alex Keybl [:akeybl] from comment #18)
> The blocklist should have gone live yesterday - we'll follow up with Jorge
> and Sheila to make sure it's enabled for all beta users and to find out
> whether or not it's lowering the crash numbers here.

This didn't happen - there were issues in bug 722538 when testing on staging that prevented this from going out. We're working with Juan/Marcia to verify before rolling out the blocklist.

Comment 20

[Scoobidiver (away)]

(In reply to Timothy Nikkel (:tn) from comment #17)
> Best theory so far is that AMD/ATI are causing this to increase (bug 728533)
> (although doesn't seem responsible for all crashes). Blocklisting those
> drivers is bug 722538.
Bug 7282533 depends on bug 722538.

Comment 21

[Alex Keybl [:akeybl]]

Bug 722538 has now been resolved - we should watch for crash numbers to drop.

Comment 22

[Alex Keybl [:akeybl]]

(In reply to Alex Keybl [:akeybl] from comment #21)
> Bug 722538 has now been resolved - we should watch for crash numbers to drop.

This does not appear to have helped. We're still seeing this crash at #23 in the top crash list for beta 4. Given where we are in the schedule and the fact that this isn't a recent regression at this point, wontfixing for FF12.

Comment 23

[Scoobidiver (away)]

(In reply to Alex Keybl [:akeybl] from comment #22)
> This does not appear to have helped.
It's the wrong bug. Bug 728533 is the right one.

Comment 24

[Scoobidiver (away)]

It's #53 top browser crasher in 13.0.1, #37 in 14.0b11, #65 in 15.0a2, and #71 in 16.0a1.

Comment 25

[Scoobidiver (away)]

Since Firefox 17, it has been a low volume crash: https://crash-stats.mozilla.com/report/list?signature=nsIFrame%3A%3ABuildDisplayListForChild%28nsDisplayListBuilder*%2C+nsIFrame*%2C+nsRect+const%26%2C+nsDisplayListSet+const%26%2C+unsigned+int%29

Comment 26

[BugBot [:suhaib / :marco]]

Crash volume for signature 'nsIFrame::BuildDisplayListForChild':
 - nightly (version 53): 13 crashes from 2016-11-14.
 - aurora  (version 52): 16 crashes from 2016-11-14.
 - beta    (version 51): 307 crashes from 2016-11-14.
 - release (version 50): 1029 crashes from 2016-11-01.
 - esr     (version 45): 291 crashes from 2016-07-06.

Crash volume on the last weeks (Week N is from 01-02 to 01-08):
            W. N-1  W. N-2  W. N-3  W. N-4  W. N-5  W. N-6  W. N-7
 - nightly       4       2       4       0       1       1       1
 - aurora        8       0       1       1       4       1       0
 - beta         34      43      43      51      56      57      17
 - release     148     171     146     179     138     144      60
 - esr          11      20      21       8      12      15       8

Affected platforms: Windows, Mac OS X, Linux

Crash rank on the last 7 days:
           Browser   Content   Plugin
 - nightly           #212
 - aurora  #954      #358
 - beta    #456      #171
 - release #574      #260
 - esr     #699

Comment 27

[Julien Cristau [:jcristau]]

Too late for firefox 52, mass-wontfix.

Comment 28

[BugBot [:suhaib / :marco]]

The bug is linked to a topcrash signature, which matches the following criterion:

• Top 10 content process crashes on beta

For more information, please visit auto_nag documentation.

Comment 29

[BugBot [:suhaib / :marco]]

Based on the topcrash criteria, the crash signatures linked to this bug are not in the topcrash signatures anymore.

For more information, please visit auto_nag documentation.

Comment 30

[Timothy Nikkel (:tnikkel)]

Only 4 crashes that are newer than 105. Lowering severity.

Comment 31

[Clouseau (:calixte)]

Crash report: https://crash-stats.mozilla.org/report/index/b682789e-6ea0-4207-bb80-8b3c70260926

Crash Reason:

EXCEPTION_ACCESS_VIOLATION_READ at 0x0000000000000033

Top 10 frames:

0  xul.dll  mozilla::DisplayListClipState::ClipContainingBlockDescendants(mozilla::nsDisplay...  layout/painting/DisplayListClipState.cpp:79
1  xul.dll  mozilla::ScrollContainerFrame::BuildDisplayList(mozilla::nsDisplayListBuilder*, ...  layout/generic/ScrollContainerFrame.cpp:4122
2  xul.dll  nsIFrame::BuildDisplayListForChild(mozilla::nsDisplayListBuilder*, nsIFrame*, mo...  layout/generic/nsIFrame.cpp:4678
3  xul.dll  nsBlockFrame::BuildDisplayList(mozilla::nsDisplayListBuilder*, mozilla::nsDispla...  layout/generic/nsBlockFrame.cpp:8653
4  xul.dll  nsIFrame::BuildDisplayListForChild(mozilla::nsDisplayListBuilder*, nsIFrame*, mo...  layout/generic/nsIFrame.cpp:4678
5  xul.dll  nsFlexContainerFrame::BuildDisplayList(mozilla::nsDisplayListBuilder*, mozilla::...  layout/generic/nsFlexContainerFrame.cpp:3040
6  xul.dll  nsIFrame::BuildDisplayListForChild(mozilla::nsDisplayListBuilder*, nsIFrame*, mo...  layout/generic/nsIFrame.cpp:4432
7  xul.dll  mozilla::ScrollContainerFrame::BuildDisplayList(mozilla::nsDisplayListBuilder*, ...  layout/generic/ScrollContainerFrame.cpp:4236
8  xul.dll  nsIFrame::BuildDisplayListForChild(mozilla::nsDisplayListBuilder*, nsIFrame*, mo...  layout/generic/nsIFrame.cpp:4663
9  xul.dll  nsBlockFrame::BuildDisplayList(mozilla::nsDisplayListBuilder*, mozilla::nsDispla...  layout/generic/nsBlockFrame.cpp:8653

Filed because this signature's crash volume spiked. 12 distinct installations hit this signature in the last 7 days (27 reports), against 2.42 expected from its own rate over the preceding 56 days -- 4.96x, normalised for the channel's daily installation count. This signature is not new: its first report is in build 20220912135840 (2022-09-12), 1474 days before this build.

Clouseau analysis (automated -- nothing below was checked by a human; a claim it could not ground is deliberately absent):

The content process crashes while building the display list, inside DisplayListClipState::InvalidateCurrentCombinedClipChain (inlined ActiveScrolledRoot::IsAncestor/Depth) at DisplayListClipState.cpp:79. It reads ActiveScrolledRoot field offset 0x30 through a pointer holding a tiny integer (fault addresses 0x32–0x3e). The nightly rise comes almost entirely from Intel Raptor Lake CPUs (family 6 model 183 stepping 1): 60 of 61 nightly reports in 60 days. 53 of those 61 carry microcode 0x11d, which predates the 0x12B update Intel shipped for this instability, and nearly all of them share one NVIDIA driver. All of the 09-20..09-23 surge carries that microcode, which points to one or a few degrading machines rather than a code change. There is no nightly software action. The long-standing release/ESR population of this signature is different: mixed CPUs and freed-memory/frame-poison addresses (0xe5e5…, 0x7ffffffff0de8…). If anything is investigated, it should be that population, as a possible use-after-free of a display-list ASR.

Possible path to the crash: Mechanism (observed): read mov edx, dword [rcx+0x30] with rcx = a small integer (0x3 in the representative report), i.e. ActiveScrolledRoot::Depth dereferencing an asr/parent pointer that is neither null nor a real address. Path (observed): ScrollContainerFrame::BuildDisplayList -> AutoSaveRestore::ClipContainingBlockDescendants -> DisplayListClipState::ClipContainingBlockDescendants -> InvalidateCurrentCombinedClipChain(asr) at line 79, with asr from aBuilder->CurrentActiveScrolledRoot(). Trigger (inferred, medium): the nightly spike reports come almost only from Raptor Lake CPUs, mostly on pre-fix microcode 0x11d with one GPU driver, so the likeliest source of the bogus pointer is CPU instability on one or a few machines. A software producer of small-integer ASR pointers cannot be excluded, but none was found and there is no non-Raptor-Lake nightly signal to support one.

Checked:

• Faulting statement is InvalidateCurrentCombinedClipChain(asr), where asr = aBuilder->CurrentActiveScrolledRoot(), in ClipContainingBlockDescendants. (layout/painting/DisplayListClipState.cpp@4395e1fc5b2a:76-79)
• Representative report: EXCEPTION_ACCESS_VIOLATION_READ at 0x33, instruction mov edx, dword [rcx + 0x30], Raptor Lake 6/183/1. (brief, report b682789e-6ea0-4207-bb80-8b3c70260926)
• Nightly, 60 days: 60 of 61 reports on family 6 model 183 stepping 1. (facets cpu_info, nightly, 60d)
• Nightly, 60 days: microcode 0x11d 53, 0x12b 6, other 2; adapter driver 32.0.16.1088 49, 32.0.15.6094 6. (facets cpu_microcode_version and adapter_driver_version, nightly, 60d)
• Every report on the surge days (09-20: 15, 09-21: 10, 09-22: 5, 09-23: 3) carries microcode 0x11d; the 09-24..09-26 tail is mostly 0x12b. (facets cpu_microcode_version by_day, nightly, 14d)
• Nightly fault addresses are mostly 0x32–0x3e (small integer base + 0x30), varying from report to report. (facets address, nightly, 60d)
• Across all channels only 41% (122/295) of reports are Raptor Lake, and the top addresses include jemalloc poison 0xe5e5e5e5e5e5e529 and 0x7ffffffff0de802f (46 reports). (facets cpu_info and address, all_channels, 60d)
• The nightly surge is concentrated on one or a few machines (a single microcode+driver combination); the pipeline's 12 'installations' is likely inflated because nightly install_time changes with every update. [inferred, medium confidence] (facets cpu_microcode_version, adapter_driver_version, install_time (distinct values clustered 09-19..09-21), nightly)

Alternatives considered:

• Changesets in the 20260925214843 pushlog window (e.g. 1333eacacf6c/ce8aea5846c2 grid-lanes, a968723abc9b sticky, d211d31352eb flex stretch): disfavored -- the surge (09-20..09-23) predates this build and is tied to one microcode/driver combination; 158.0a1 was already at 3.5/1000.
• A software regression in 158.0a1 as the nightly cause: disfavored -- 98% of nightly reports are on one CPU model, mostly with a single microcode+driver, and no non-Raptor-Lake nightly cohort grew.
• Pipeline's hardware abstention: corroborated and refined -- it is also a concentration on pre-0x12B microcode on essentially one machine.

Worth checking first:

• Release/ESR cohort with poison addresses (0xe5e5…, 0x7ffffffff0de8…) on mixed CPUs: may be a real use-after-free of an ActiveScrolledRoot or clip chain across display-list rebuilds; read a few release reports with those addresses and check whether retained display lists or CurrentActiveScrolledRoot outlive their arena.
• Whether the 0x12b-microcode tail (6 reports, driver 32.0.15.6094) is a second degraded machine or a software signal: watch whether it persists on 159 builds from CPUs other than Raptor Lake.

Filed automatically by Clouseau, which analyses nightly crashes with an LLM. Nothing above was written or checked by a human. Please close it as INVALID if it is wrong — that is useful feedback, not a nuisance.

This is not an independent Mozilla discovery: the crash is known here only because somebody submitted the crash report linked at the top. If this duplicates an existing report, please resolve THIS bug as the duplicate and leave the credit with the earlier reporter.

Posted here because mozilla::ActiveScrolledRoot::Depth is another spelling of this bug's signature @0x0 | nsIFrame::BuildDisplayListForChild (frame mozilla::ActiveScrolledRoot::Depth replaced @0x0, nsIFrame::BuildDisplayListForChild); [@ mozilla::ActiveScrolledRoot::Depth] has been added to its crash signatures.

Comment 32

[Timothy Nikkel (:tnikkel)]

I don't think we should add the signature ActiveScrolledRoot::Depth to this bug, that's already covered by bug 1840362 and will just makes things more confusing here.

(In reply to Clouseau (:calixte) from comment #31)

The nightly rise comes almost entirely from Intel Raptor Lake CPUs (family 6 model 183 stepping 1): 60 of 61 nightly reports in 60 days.

This seems to be the summary of the new information.