Closed Bug 1744069 Opened 3 years ago Closed 3 years ago

Crash in [@ mozilla::nsDisplayListBuilder::BuildCompositorHitTestInfoIfNeeded]

Categories

(Core :: Web Painting, defect)

defect

Tracking

()

VERIFIED FIXED
100 Branch
Tracking Status
firefox-esr91 --- unaffected
firefox98 --- unaffected
firefox99 blocking verified
firefox100 + verified

People

(Reporter: sefeng, Assigned: mikokm)

References

(Regression)

Details

(4 keywords)

Crash Data

Attachments

(1 file)

Maybe Fission related. (DOMFissionEnabled=1)

Crash report: https://crash-stats.mozilla.org/report/index/7f797ae1-7d94-46d5-984e-087cf0211127

MOZ_CRASH Reason: MOZ_DIAGNOSTIC_ASSERT(false) (Duplicate display item!)

Top 10 frames of crashing thread:

0 XUL mozilla::nsDisplayListBuilder::BuildCompositorHitTestInfoIfNeeded layout/painting/nsDisplayList.cpp:1980
1 XUL mozilla::SVGOuterSVGFrame::BuildDisplayList layout/svg/SVGOuterSVGFrame.cpp:775
2 XUL nsIFrame::BuildDisplayListForChild layout/generic/nsIFrame.cpp:4286
3 XUL nsBlockFrame::BuildDisplayList layout/generic/nsBlockFrame.cpp:7096
4 XUL nsIFrame::BuildDisplayListForChild layout/generic/nsIFrame.cpp:4286
5 XUL nsGridContainerFrame::BuildDisplayList layout/generic/nsGridContainerFrame.cpp:9383
6 XUL nsIFrame::BuildDisplayListForChild layout/generic/nsIFrame.cpp:4268
7 XUL nsBlockFrame::BuildDisplayList layout/generic/nsBlockFrame.cpp:7096
8 XUL nsIFrame::BuildDisplayListForChild layout/generic/nsIFrame.cpp:4059
9 XUL nsBlockFrame::BuildDisplayList layout/generic/nsBlockFrame.cpp:7096
Crash Signature: [@ mozilla::nsDisplayListBuilder::BuildCompositorHitTestInfoIfNeeded] → [@ mozilla::nsDisplayListBuilder::BuildCompositorHitTestInfoIfNeeded] [@ mozilla::AssertUniqueItem ]

Potentially it might be possible to reproduce this for someone who has access to the urls of the crashes.

16 crashes from 11 installations with Firefox 99.0b1 shortly after it got released today. Is this related to the changes in bug 1714584?

Flags: needinfo?(mikokm)
Crash Signature: [@ mozilla::nsDisplayListBuilder::BuildCompositorHitTestInfoIfNeeded] [@ mozilla::AssertUniqueItem ] → [@ mozilla::nsDisplayListBuilder::BuildCompositorHitTestInfoIfNeeded] [@ mozilla::AssertUniqueItem] [@ mozilla::nsDisplayList::AppendNewToTopWithIndex<T>]
Crash Signature: [@ mozilla::nsDisplayListBuilder::BuildCompositorHitTestInfoIfNeeded] [@ mozilla::AssertUniqueItem] [@ mozilla::nsDisplayList::AppendNewToTopWithIndex<T>] → [@ mozilla::AssertUniqueItem] [@ mozilla::nsDisplayList::AppendNewToTopWithIndex<T>] [@ mozilla::nsDisplayListBuilder::BuildCompositorHitTestInfoIfNeeded] [@ nsIFrame::BuildDisplayListForChild]

I have been trying to reproduce this bug with the crash report URLs without success. If someone can reproduce this reliably, it would be extremely helpful.

Flags: needinfo?(mikokm)
Keywords: testcase-wanted

Are we seeing anything like this in the fuzzers?

Flags: needinfo?(jkratzer)

I've managed to reproduce crash with this site: https://thejigsawpuzzles.com/Puzzle-of-the-Day/Las-Vegas_2-jigsaw-puzzle

Unfortunately, the page is a bit complicated and also reliably crashes rr when I try to record the crash.

:RyanVM, unfortunately not. The nearest stack I see was filed in bug 1648628.

Flags: needinfo?(jkratzer)
Crash Signature: [@ mozilla::AssertUniqueItem] [@ mozilla::nsDisplayList::AppendNewToTopWithIndex<T>] [@ mozilla::nsDisplayListBuilder::BuildCompositorHitTestInfoIfNeeded] [@ nsIFrame::BuildDisplayListForChild] → [@ mozilla::AssertUniqueItem] [@ mozilla::nsDisplayList::AppendNewToTopWithIndex<T>] [@ mozilla::nsDisplayListBuilder::BuildCompositorHitTestInfoIfNeeded] [@ nsIFrame::BuildDisplayListForChild] [@ nsTextFrame::BuildDisplayList]

:miko how feasible would it be to blackout bug 1714584
Given the crash rate volume and investigation problems

Flags: needinfo?(mikokm)

(In reply to Donal Meehan [:dmeehan] from comment #7)

:miko how feasible would it be to blackout bug 1714584
Given the crash rate volume and investigation problems

The link to the bug is pointing to an invalid location(=17145840 instead of =1714584).

(In reply to Arthur K. [He/Him] from comment #8)

(In reply to Donal Meehan [:dmeehan] from comment #7)

:miko how feasible would it be to blackout bug 1714584
Given the crash rate volume and investigation problems

The link to the bug is pointing to an invalid location(=17145840 instead of =1714584).

URL fixed, thanks

(In reply to Donal Meehan [:dmeehan] from comment #7)

:miko how feasible would it be to blackout bug 1714584
Given the crash rate volume and investigation problems

I think it is possible. Bug 1757184 should be backed out first in that case.

Flags: needinfo?(mikokm)

I took a look at that and rev a261bb633790 doesn't back out cleanly. Looks like it needs a bit of rebasing. Can you please post a backout patch?

Flags: needinfo?(mikokm)
Keywords: topcrash
Assignee: nobody → mikokm
Status: NEW → ASSIGNED
Flags: needinfo?(mikokm)

This was a tricky bug to figure out. The crashing website also triggers another assertion1 about "unmodified subtree optimization" of merging retained display lists.

The actual bug is that the patch for bug 1714584 changed the display list preprocessing behavior slightly by always emptying the child lists fully. The merging RDL code expects that display list is kept intact when the above "keep linked" optimization fails. I have restored this behavior.

Regressed by: 1714584

Set release status flags based on info from the regressing bug 1714584

Miko,

A bit tough to see the number 1 (right after assertion) from comment 13.

Reminder: :miko Please submit a beta uplift request when this is ready for an uplift. This is a top crash in 99.

Pushed by mikokm@gmail.com: https://hg.mozilla.org/integration/autoland/rev/844b96d8f690 Restore the previous behavior of merging RDL list traversal r=emilio

Comment on attachment 9267532 [details]
Bug 1744069 - Restore the previous behavior of merging RDL list traversal r=emilio

Beta/Release Uplift Approval Request

  1. Wait for the jigsaw puzzle to load
  2. If no crash, refresh to repeat. The crash rate should be fairly high (30-50%)
  • List of other uplifts needed: None
  • Risk to taking this patch: Low
  • Why is the change risky/not risky? (and alternatives if risky): The patch restores the previous behavior that was changed in bug 1714584.
  • String changes made/needed:
Attachment #9267532 - Flags: approval-mozilla-beta?
Flags: qe-verify+

Note that the crash is not reproducible in Nightly unless the pref layout.display-list.retain.sc is changed to false. The default value will change to false when bug 1759514 lands.

Status: ASSIGNED → RESOLVED
Closed: 3 years ago
Resolution: --- → FIXED
Target Milestone: --- → 100 Branch

Comment on attachment 9267532 [details]
Bug 1744069 - Restore the previous behavior of merging RDL list traversal r=emilio

Approved for 99.0b4. Thanks.

Attachment #9267532 - Flags: approval-mozilla-beta? → approval-mozilla-beta+

(In reply to Worcester12345 from comment #16)

Not sure if this is the same thing:

https://crash-stats.mozilla.org/report/index/3e7ff23a-142b-475c-8705-cdd8d0220310

Yes? No?

QA Whiteboard: [qa-triaged]

Reproduced the initial issue on Firefox 99 beta 3 on macOS Big Sur 11.6.

Verified as fixed on the latest Nightly 100.0a1 on macOS Big Sur 11.6, Windows 10 x64, and Ubuntu 20.04 - no crash occurs when following the steps from Comment 19 and the pref layout.display-list.retain.sc is set to false.

Verified as fixed on Firefox 99 beta 4 on macOS Big Sur 11.6, Windows 10 x64, and Ubuntu 20.04 x64.

Status: RESOLVED → VERIFIED
QA Whiteboard: [qa-triaged]
Flags: qe-verify+
Regressions: 1760344
No longer regressions: 1760344
Regressions: 1760847
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: