1262282 - 46.0b7 crash spike in mozilla::DisplayListClipState::AutoSaveRestore::InsertInactiveScrollClipForContainingBlockDescendants

Status: RESOLVED WORKSFORME

(Core :: Web Painting, defect)

Description

[[:philipp]]

This bug was filed from the Socorro interface and is 
report bp-899abfa8-5a8a-4b02-877f-729ce2160405.
=============================================================
Crashing Thread (0)
Frame 	Module 	Signature 	Source
0 	xul.dll 	mozilla::DisplayListClipState::AutoSaveRestore::InsertInactiveScrollClipForContainingBlockDescendants(nsDisplayListBuilder*, nsIScrollableFrame*) 	layout/base/DisplayListClipState.h
1 	xul.dll 	mozilla::ScrollFrameHelper::BuildDisplayList(nsDisplayListBuilder*, nsRect const&, nsDisplayListSet const&) 	layout/generic/nsGfxScrollFrame.cpp
2 	xul.dll 	nsIFrame::BuildDisplayListForStackingContext(nsDisplayListBuilder*, nsRect const&, nsDisplayList*) 	layout/generic/nsFrame.cpp
3 	xul.dll 	nsIFrame::BuildDisplayListForChild(nsDisplayListBuilder*, nsIFrame*, nsRect const&, nsDisplayListSet const&, unsigned int) 	layout/generic/nsFrame.cpp
4 	xul.dll 	DisplayLine 	layout/generic/nsBlockFrame.cpp
5 	xul.dll 	nsBlockFrame::BuildDisplayList(nsDisplayListBuilder*, nsRect const&, nsDisplayListSet const&) 	layout/generic/nsBlockFrame.cpp

this crash signature is just popping up for the first time in 46.0b7 for a couple of installs at the same time. curiously it is only affecting amd gpus so far. 
the crash is low volume with ~0.15% of crashes for this beta though.

Comment 1

[[:philipp]]

could you take a look here, since this seems to happen in code from bug 1147673?

Comment 2

[Markus Stange [:mstange]]

jrmuizel and I had a look at this today. The crash happens when we try to execute an instruction at 0x3c4e23 (relative to xul.dll). However, in the code we're executing, there's a "call" instruction at 0x3c4e22, and it seems like we're overshooting this instruction by 1 byte. So the processor interprets the code as a different instruction (return with offset).
We don't know how our instruction pointer could have become corrupted like this.
We also don't have an explanation for the crash address being 0xffffffffffffffff.
The stack itself looks very reasonable. It seems like we were just about to execute the "call" instruction before we got misplaced.

Comment 3

[Markus Stange [:mstange]]

The Build Architecture Info field here says AuthenticAMD family 20 model 2 stepping 0 | 2, so could this be another instance of bug 772330?

Comment 4

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

For the spike in 46.0b7, yes, it does look like it is.

(I see two other crashes with this signature since April 1 that weren't 46.0b7, and those were on other types of CPUs.)

I didn't debug a minidump to verify that it fits the other symptoms, though.

Comment 5

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

Oh, but comment 2 sounds a lot like it.

Comment 6

[[:philipp]]

there are no recent crashes of this anymore