1437515 - Crash in AdjustViews

Status: RESOLVED WORKSFORME

(Core :: Layout, defect, P2)

Description

[Marcia Knous [:marcia]]

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

Seen while looking at Android nightly stats: http://bit.ly/2o4NNfJ. Two similar signatures. All the comments seem to mention scrolling.

Comments:
I was just scrolling through the page. 

Possible regression range based on Build ID: https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=92b6195a9367dec27fbf3efbe7824cf163aa017a&tochange=cac3a4e6000d7079f8cf0118a5c509b2527b3289

Top 10 frames of crashing thread:

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

=============================================================

Comment 1

[Botond Ballo [:botond]]

Moving to Layout based on the stack trace. Nothing in the possible regression range jumps out to me.

Comment 2

[Jet Villegas (inactive)]

[ Triage 2017/02/20: P2 ] P2 bugs may become P1's after further analysis. Please prioritize diagnosis and repair.

Comment 3

[Marcia Knous [:marcia]]

Looks like the volume tapered off - there were crashes starting in Build 20180204102100 and they seemed to have stopped in 20180218100125 - [@ @0x0 | AdjustViews ].

Comment 4

[Marcia Knous [:marcia]]

Based on Comment 3 I will close this one out for now as WFM. Please reopen if you see signatures showing up again.

Comment 5

[Calixte Denizet (:calixte)]

The signature is came back in build 20180305100140 (FennecAndroid) with 8 crashes for 5 installs.

Comment 6

[Emilio Cobos Álvarez [: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?

Comment 7

[Kartikaya Gupta (email:[e-mail])]

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.

[1] https://crash-stats.mozilla.com/report/index/c6e561fa-97ef-43dd-93fc-927d60180307

Comment 8

[Kartikaya Gupta (email:[e-mail])]

Also given the line of the crash is
  aFrame->GetParent()->GetClosestView(&pt);

I think there's some existing bugs on file that might be the same root cause.

Comment 9

[Botond Ballo [:botond]]

I don't have anything to add to what Kats said.

Comment 10

[Timothy Nikkel (:tnikkel)]

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.

Comment 11

[Marcia Knous [:marcia]]

Trivial crashes in recent builds. Resolving as WFM.