1437436 - Crash in <name omitted> | nsIFrame::IsVisibleConsideringAncestors

Status: RESOLVED WORKSFORME

(Core :: Layout, defect)

Description

[Calixte Denizet (:calixte)]

This bug was filed from the Socorro interface and is
report bp-f9b0beeb-efa1-4111-9bfc-890d70180211.
=============================================================

Top 10 frames of crashing thread:

0 libxul.so <name omitted> gfx/layers/ipc/CompositorBridgeChild.h:188
1 libxul.so nsIFrame::IsVisibleConsideringAncestors obj-firefox/dist/include/nsStyleStructList.h:62
2 libxul.so nsPresContext::NotifyDidPaintForSubtree layout/base/nsPresContext.cpp:2750
3 libxul.so nsPresContext::NotifyDidPaintSubdocumentCallback layout/base/nsPresContext.cpp:2699
4 libxul.so nsDocument::EnumerateSubDocuments dom/base/nsDocument.cpp:8227
5 libxul.so nsPresContext::NotifyDidPaintForSubtree layout/base/nsPresContext.cpp:2786
6 libxul.so nsPresContext::NotifyDidPaintSubdocumentCallback layout/base/nsPresContext.cpp:2699
7 libxul.so nsDocument::EnumerateSubDocuments dom/base/nsDocument.cpp:8227
8 libxul.so nsPresContext::NotifyDidPaintForSubtree layout/base/nsPresContext.cpp:2786
9 libxul.so mozilla::layers::GenericNamedTimerCallback<>::Notify layout/base/nsPresContext.cpp:3449

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

There are 330 crashes (from 121 installations) in nightly 60 with buildid 20180211100158. In analyzing the backtrace, the regression may have been introduced by patch [1] to fix bug 1429932.

[1] https://hg.mozilla.org/mozilla-central/rev?node=39ffcc432d0c

Comment 1

[Marcia Knous [:marcia]]

This has quickly risen to top crash status on Fennec nightly, 548 crashes/193 installs.

Comment 2

[Matt Woodrow (:mattwoodrow)]

Bug 1429932 did touch a line in that stack trace, but it shouldn't have affected what gets called and when.

I also see crashes like [1] that have a different stack trace, and don't go through the modified code at all.

The regression range from the 10th nightly to the 11th is this: https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=a8e153c55eeee93a11e87d325fb20c644421036f&tochange=2b7d42d527af582a465e49187fe387442d524a7c

I really don't see anything relevant in there though, is it possible that nobody used the 10th nightly and the regression was a day earlier?


[1] https://crash-stats.mozilla.com/report/index/d93b9f68-5ab2-4477-820e-fc1bd0180211

Comment 3

[Marcia Knous [:marcia]]

I see crashes going back to 20180204102100, which means https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=92b6195a9367dec27fbf3efbe7824cf163aa017a&tochange=cac3a4e6000d7079f8cf0118a5c509b2527b3289 might be a better changeset to use.

Comment 4

[Marcia Knous [:marcia]]

Hi Jet - Can you help us track down this regression? Over 1300 crashes in the last few days.

Comment 5

[Marcia Knous [:marcia]]

This crash seems to have been stopped in the 20180213 build, but I don't know what to attribute that to.

Comment 6

[Calixte Denizet (:calixte)]

The signature is back in build 20180218100125 (17 crashes).
:bz, could you help here ?

Comment 7

[Boris Zbarsky [:bzbarsky]]

Lots of near-null crashes there, but everything I see in IsVisibleConsideringAncestors seems to be getting null-checked correctly....

The actual crash is claimed to be in CompositorBridgeChild::GetMessageLoop, but I don't quite see how IsVisibleConsideringAncestors would call it.

Can we get anything like a regression range from crash-stats?  This looks like it's Android-only, right?

Comment 8

[Julien Cristau [:jcristau]]

Removing the blocking flag.  It looks like the Feb 11 and Feb 12 nightlies were very crashy but this went back down later on.

Comment 9

[Marcia Knous [:marcia]]

Bug 1436060 which has a different signature looks to be related to this, as it follows the same pattern of crashes as this one.

Both signatures are Android only. I will work on getting a better regression range from crash-stats.

Comment 10

[Marcia Knous [:marcia]]

https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=92b6195a9367dec27fbf3efbe7824cf163aa017a&tochange=cac3a4e6000d7079f8cf0118a5c509b2527b3289 is the changeset that I see according to crash stats, with crashes in this signature first appearing in 20180204102100, which seems to be the same one I posted in Comment 3.

Comment 11

[Jet Villegas (inactive)]

Emilio: can you have a look? of all the check-ins from comment 10, the only suspect I could smell is:
https://hg.mozilla.org/mozilla-central/rev/ccd78a806809

In particular, the change to using initial values vs. device default values may explain why this is Android-only? That said, I don't know how the call stack reported is even possible.

Comment 12

[Emilio Cobos Álvarez [:emilio]]

It doesn't really ring any bell, sorry. initial values are exactly the same as the device's default values.

The stack _is_ possible, via PresShell::IsVisible, but I have no idea how this can happen either, looking at the function there's no missing check at all.

Comment 13

[Milan Sreckovic [:milan] (needinfo for best results)]

Given the info that we have, are we stuck or can we move it forward?  Why the intense spike?

Comment 14

[[:philipp]]

the last crashing fennec build was 20180218100125, nothing in the last 10 days any more so perhaps something else fixed this?

Comment 15

[Emilio Cobos Álvarez [:emilio]]

(In reply to Milan Sreckovic [:milan] from comment #13)
> Given the info that we have, are we stuck or can we move it forward?  Why
> the intense spike?

I have no idea, as I said. The spike seems to match the period bug 1436904 was on nightly though.

Comment 16

[Marcia Knous [:marcia]]

Per triage closing as WFM. Please reopen if we see the crash come back in high volume.