Open Bug 1437515 Opened 2 years ago Updated 2 years ago

Crash in AdjustViews


(Core :: Layout, defect, P2, critical)




Tracking Status
firefox60 --- fix-optional


(Reporter: marcia, Unassigned)


(Keywords: crash, regression)

Crash Data

This bug was filed from the Socorro interface and is
report bp-f9db7cd3-a0cf-4506-a232-9d4be0180204.

Seen while looking at Android nightly stats: Two similar signatures. All the comments seem to mention scrolling.

I was just scrolling through the page. 

Possible regression range based on Build ID:

Top 10 frames of crashing thread:

0  @0xfffdc3a8 
1 AdjustViews layout/generic/nsGfxScrollFrame.cpp:2454
2 nsFrame::GetChildLists layout/generic/nsFrame.cpp:1948
3 mozilla::layout::FrameChildListIterator::FrameChildListIterator layout/generic/FrameChildList.cpp:17
4 AdjustViews layout/generic/nsGfxScrollFrame.cpp:2474
5 nsIFrame::MarkNeedsDisplayItemRebuild layout/generic/nsFrame.cpp:1038
6 mozilla::ScrollFrameHelper::ScrollVisual layout/generic/nsGfxScrollFrame.cpp:2652
7 mozilla::ScrollFrameHelper::ScrollToImpl layout/generic/nsGfxScrollFrame.cpp:2879
8 dalvik-main space 1 (deleted) dalvik-main space 1 @0x13e8c0fe 
9 mozilla::ScrollFrameHelper::GetScrolledRect layout/generic/nsGfxScrollFrame.cpp:6066

Moving to Layout based on the stack trace. Nothing in the possible regression range jumps out to me.
Component: Panning and Zooming → Layout
[ Triage 2017/02/20: P2 ] P2 bugs may become P1's after further analysis. Please prioritize diagnosis and repair.
Priority: -- → P2
Looks like the volume tapered off - there were crashes starting in Build 20180204102100 and they seemed to have stopped in 20180218100125 - [@ @0x0 | AdjustViews ].
Based on Comment 3 I will close this one out for now as WFM. Please reopen if you see signatures showing up again.
Closed: 2 years ago
Resolution: --- → WORKSFORME
The signature is came back in build 20180305100140 (FennecAndroid) with 8 crashes for 5 installs.
Resolution: WORKSFORME → ---
Flags: needinfo?(emilio)
The only thing I see particularly in common across those crashes is that they have nsIFrame::MarkNeedsDisplayItemRebuild and scrolling stuff in the stack.

Looks like a bunch (all?) of them have AsynPanZoomController::RequestContentRepaint in the stack, and ScrollFrameHelper::ScrollVisual, which looks believable looking at all the APZCCallbackHelper::UpdateRootFrame stuff.

I.. do not know much about APZ though, Botond / Kats, any idea?
Flags: needinfo?(emilio)
Flags: needinfo?(bugmail)
Flags: needinfo?(botond)
The stack itself seems generally reasonable, at least in the crash I looked at [1]. There's some weird stack frames, but overall it looks like the main-thread gets a APZ repaint request (the stuff in APZCCallbackHelper) which then triggers a scroll (the stuff in ScrollFrameHelper) and that then goes into the recursive AdjustViews function which seems to walk the frame tree and adjust coordinates. However at some point deep in that walk it crashes.

The stack frame pointing to MarkNeedsDisplayItemRebuild seems out of place, not sure where that's coming from, but that sounds related to retained display lists. I don't see any patches related to that landing around when this started, so I suspect that's just a red herring.

Redirecting to :tnikkel who probably knows more about AdjustViews and why it might be crashing.

Flags: needinfo?(bugmail) → needinfo?(tnikkel)
Also given the line of the crash is

I think there's some existing bugs on file that might be the same root cause.
I don't have anything to add to what Kats said.
Flags: needinfo?(botond)
I agree with everything kats said.

The only reason I could see that this is crashing is that the frame or view tree was already messed up or in an unexpected or inconsistent state before the AdjustViews call, maybe even before the AsyncPanZoomController::RequestContentRepaint call at the base of this stack. I can't see anything that AdjustViews itself could cause anything to get destroyed.
Flags: needinfo?(tnikkel)
You need to log in before you can comment on or make changes to this bug.