1845647 - Crash in [@ nsLayoutUtils::GetScrollableFrameFor]

Status: RESOLVED INVALID

(Core :: Layout, defect)

Description

[Ryan VanderMeulen [:RyanVM]]

Crash report: https://crash-stats.mozilla.org/report/index/81f8c9d2-290d-42ca-a296-696d30230727

Reason: EXCEPTION_ACCESS_VIOLATION_READ

Top 10 frames of crashing thread:

0  xul.dll  nsLayoutUtils::GetScrollableFrameFor  layout/base/nsLayoutUtils.cpp:1368
0  xul.dll  nsIFrame::GetCompositorHitTestArea  layout/generic/nsIFrame.cpp:11061
0  xul.dll  mozilla::HitTestInfo::Initialize  layout/painting/HitTestInfo.cpp:59
0  xul.dll  mozilla::nsDisplayCompositorHitTestInfo::nsDisplayCompositorHitTestInfo  layout/painting/nsDisplayList.h:4694
0  xul.dll  mozilla::MakeDisplayItemWithIndex  layout/painting/nsDisplayList.h:1970
0  xul.dll  mozilla::nsDisplayList::AppendNewToTopWithIndex  layout/painting/nsDisplayList.h:3079
0  xul.dll  mozilla::nsDisplayList::AppendNewToTop  layout/painting/nsDisplayList.h:3072
0  xul.dll  mozilla::nsDisplayListBuilder::BuildCompositorHitTestInfoIfNeeded  layout/painting/nsDisplayList.cpp:2027
1  xul.dll  nsIFrame::DisplayBackgroundUnconditional  layout/generic/nsIFrame.cpp:2655
1  xul.dll  nsIFrame::DisplayBorderBackgroundOutline  layout/generic/nsIFrame.cpp:2673

Comment 1

[Daniel Holbert [:dholbert]]

I took a quick look at the minidump for comment 0's linked crash report (in 117.0a1). I think it might be a bit-flip in a vtable pointer?

We're crashing with an access violation reading address 0x00007dfc8bd24aa0, when executing the last line here:

nsIScrollableFrame* nsLayoutUtils::GetScrollableFrameFor(
    const nsIFrame* aScrolledFrame) {
  nsIFrame* frame = aScrolledFrame->GetParent();
  nsIScrollableFrame* sf = do_QueryFrame(frame);
  return (sf && sf->GetScrolledFrame() == aScrolledFrame) ? sf : nullptr;

Visual Studio shows sf as being kinda suspicious, and it shows its vtable pointer as being 0x00007dfc8bd24a30 which is 0x70 lower than the value that we're crashing on. So I think that means we're crashing when trying to index into the vtable of sf to look up the virtual function pointer for sf->GetScrolledFrame().

So. Having established that: is that vtable pointer actually legitimate?

If I look at other objects here, e.g. aScrolledFrame, it looks like a perfectly reasonable object, and in fact it has a perfectly reasonable nsHTMLScrollFrame parent which seems to be what this function is checking for. Most suspicious, its own (working-just-fine) vtable pointer has nearly the same high-order bits as the vtable pointer for sf, except it's got a single high bit flipped.

vtable pointer for sf vs. aScrolledFrame:

0x00007dfc8bd24a30
0x00007ffc8bd223b0
      -^------

Note the 7ff vs 7df in the high-order bits (with following digits being identical). d vs. f is a single bit flip which has these vtable pointers pointing at radically different locations, which seems suspect. If I assume that 7df was really supposed to say 7ff, then instead these vtable pointers aren't radically different and are just offset by 0x2680 which seems believable for spacing between vtables of different but related classes.

Comment 2

[Daniel Holbert [:dholbert]]

I looked at bp-533b3fc3-f8ec-4de7-881b-7d9960230630 which is a crash in 116.0a1 Nightly, and it looks like the same thing.

vtable pointer for sf vs. aScrolledFrame:

0x00007ffbd5ca01f0
0x00007fffd5ca2e70
      ---^----

Again, the high bits are all the same, except for a single bit flip in the middle (giving us a b i.e. 1011 where we should have a f i.e. 1111). That seems likely to be a bad-RAM bitflip error which makes our vtable pointer point at the entirely wrong area of memory (and hence we get an access violation when making a virtual function call there).

So those two crash reports at least seem pretty definitively to be random bit-flips from bad hardware. The crash volume here is low enough that it seems likely the other ones could all be explained by the same reason.

I suspect that means we can call this as INVALID? CC'ing gsvelto in case he's got any interest/recommenations for other actions here, since he's helped with diagnosing other bit-flip crashes in the past.