1431147 - Crash in nsIFrame::RemoveDisplayItemDataForDeletion

Status: RESOLVED INCOMPLETE

(Core :: Web Painting, defect, P3)

Description

[Calixte Denizet (:calixte)]

This bug was filed from the Socorro interface and is
report bp-3b3b5a41-f4b9-409a-890b-77d7a0180117.
=============================================================

Top 10 frames of crashing thread:

0 libxul.so nsIFrame::RemoveDisplayItemDataForDeletion [clone .cold.853] 
1 libxul.so mozilla::PresShell::NotifyDestroyingFrame 
2 libxul.so nsFrame::DestroyFrom 
3 libxul.so nsCanvasFrame::DestroyFrom 
4 libxul.so nsContainerFrame::DestroyFrom 
5 libxul.so nsContainerFrame::DestroyFrom 
6 libxul.so nsIFrame::Destroy layout/generic/nsIFrame.h:687
7 libxul.so nsFrameManager::Destroy 
8 libxul.so mozilla::PresShell::Destroy 
9 libxul.so nsDocumentViewer::DestroyPresShell 

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

There are 59 crashes in nightly 59 with buildid 20180117100129. In analyzing the backtrace, the regression may have been introduced by patch [1] to fix bug 1429961. 

[1] https://hg.mozilla.org/mozilla-central/rev/5bceb041669b

Comment 1

[Emilio Cobos Álvarez (:emilio)]

There are crashes that were way older than that bug (which was fixed yesterday), so it seems somewhat unlikely.

That function was added for retained-dl. The crash looks like a null deref, maybe from the root frame's ModifiedFrameProperty Matt, Miko, does that ring any bell? Should we land a couple diagnostic asserts around there?

Comment 2

[Miko Mynttinen]

Possibly related to bug 1418807. I'll look into adding some assertions for bugs like this.

Comment 3

[Adam Stevenson [:adamopenweb]]

I'm reproducing this crash on messenger.com. Each time it loads I get a crash in Firefox 59.0a1 (2018-01-17) for OSX 10.12.6

Was brought to my attention here: https://webcompat.com/issues/14905

Comment 4

[Matt Woodrow (:mattwoodrow)]

The spike (and reproducible crash) here was because of the first version of bug 1420737, which should be fixed now.

Comment 5

[Matt Woodrow (:mattwoodrow)]

Dropping the priority, since this is a very low volume crash normally.

Comment 6

[Jan-Ivar Bruaroey [:jib] (needinfo? me)]

This seems like a serious regression. I just opened a fiddle https://jsfiddle.net/jib1/nu2psx9q/ in Nightly today, and I think I tabbed away or something and came back, and the page was black, and every second or so flipping to white and then back to black. After a few seconds of that it crashed with bp-3eefaede-8778-4909-b185-f005b0180118

I haven't tried to reproduce yet, but I use jsfiddle frequently enough to suspect a recent regression.

Comment 7

[Jan-Ivar Bruaroey [:jib] (needinfo? me)]

I'm OSX.

Comment 9

[Andrew McCreight [:mccr8]]

(In reply to Matt Woodrow (:mattwoodrow) from comment #4)
> The spike (and reproducible crash) here was because of the first version of
> bug 1420737, which should be fixed now.

I can confirm that this spike has gone away in the 1-18 build. I don't think it is worthwhile to leave this bug open for a low volume crash that has been around for a while...

Comment 10

[Andrew McCreight [:mccr8]]

Well, maybe the 1-18 builds haven't gone out yet.

Comment 11

[Matt Woodrow (:mattwoodrow)]

As expected, the crash rate has dropped away here.

I see 13 crashes for 59.0b in the past week, and 6 are from the same install time. I don't think there's much more we need to do here.

Comment 12

[Daniel Veditz [:dveditz]]

Assigning unowned critical/high security bugs to triage owner. Please find an appropriate assignee for this bug.

Comment 13

[Randell Jesup [:jesup] (needinfo me)]

All but 1 crash (of 9) in the last two weeks in 60a1 was a BREAKPOINT (or DUMP_REQUESTED).  The one READ error was an 0xfffffff :-(  Did we land a new assertion there?  Does that help?  If this continues, it helps from a sec perspective.

Quite a few 59bN crashes with wildptrs - if the assertion is a) cheap and b) low-risk, maybe we can uplift it?

Total crashes is ~40/week; not high.

Comment 14

[Frederik Braun [:freddy]]

There are still READ and write crashes for Firefox 60. I don't think we caught this with a new assertion.

Comment 15

[Matt Woodrow (:mattwoodrow)]

The initial spike that caused this bug to be reported has been fixed, and now we just have a low volume crash that has been around a while.

It looks like an invalid pointer in the frame tree, and we're crashing trying to access frame properties on it, similar to other crashes.

No URLs or STR in the reports, so marking this as stalled for now.

Comment 16

[David Lawrence [:dkl]]

Removing employee no longer with company from CC list of private bugs.

Comment 17

[BugBot [:suhaib / :marco/ :calixte]]

The bug assignee didn't login in Bugzilla in the last 7 months and this bug has severity 'critical'.
:miko, could you have a look please?
For more information, please visit auto_nag documentation.

Comment 18

[Tom Ritter [:tjr] (OOTO until 4/30 at least)]

Still a steady stream of 60-80 crashes per release, but a generally high confidence that there are bit-flip related errors. No movement in years, we are trying remove unactionable issues.

Comment 19

[BugBot (nomail) [:suhaib / :marco/ :calixte]]

Since the bug is closed, the stalled keyword is now meaningless.
For more information, please visit BugBot documentation.