Open Bug 1427792 Opened 7 years ago Updated 2 years ago

Assertion failure: IsAncestor(aOne, aTwo) || IsAncestor(aTwo, aOne), at /builds/worker/workspace/build/src/layout/painting/nsDisplayList.h:276

Categories

(Core :: Web Painting, defect, P3)

Product:
Core
Component:
Web Painting
Version:
59 Branch
Type:
defect

Tracking

()

Tracking Flags:
Tracking Status
firefox59 --- affected
firefox60 --- affected
firefox61 --- affected
firefox62 --- affected

People

(Reporter: jkratzer, Unassigned)

References

(Blocks 2 open bugs)

Details

(Keywords: assertion, testcase)

Crash Data

Attachments

(3 files, 1 obsolete file)

A backtrace
(deleted), text/plain
Details
Detailed Crash Information
(deleted), text/plain
Details
Testcase
(deleted), application/octet-stream
Details
Attached file trigger.html (obsolete) (deleted) —
Testcase found while fuzzing mozilla-central rev ac93fdadf102. rax = 0x0000000000000000 rdx = 0x0000000000000000 rcx = 0x00007f3d8e2312ad rbx = 0x00007f3d6aa1c440 rsi = 0x00007f3d8e500770 rdi = 0x00007f3d8e4ff540 rbp = 0x00007ffd77f18040 rsp = 0x00007ffd77f18030 r8 = 0x00007f3d8e500770 r9 = 0x00007f3d8f7e6740 r10 = 0x0000000000000039 r11 = 0x0000000000000000 r12 = 0x00007f3d6aa1c600 r13 = 0x00007ffd77f182b0 r14 = 0x00007ffd77f18001 r15 = 0x00007f3d6bee5000 rip = 0x00007f3d7eec74aa OS|Linux|0.0.0 Linux 4.4.0-104-generic #127-Ubuntu SMP Mon Dec 11 12:16:42 UTC 2017 x86_64 CPU|amd64|family 6 model 78 stepping 3|1 GPU||| Crash|SIGSEGV|0x0|0 0|0|libxul.so|mozilla::ActiveScrolledRoot::PickAncestor|hg:hg.mozilla.org/mozilla-central:layout/painting/nsDisplayList.h:ac93fdadf102|276|0x18 0|1|libxul.so|nsDisplayListBuilder::AutoContainerASRTracker::~AutoContainerASRTracker|hg:hg.mozilla.org/mozilla-central:layout/painting/nsDisplayList.h:ac93fdadf102|1316|0x13 0|2|libxul.so|nsIFrame::BuildDisplayListForChild|hg:hg.mozilla.org/mozilla-central:layout/generic/nsFrame.cpp:ac93fdadf102|3700|0x8 0|3|libxul.so|DisplayRows|hg:hg.mozilla.org/mozilla-central:layout/tables/nsTableRowGroupFrame.cpp:ac93fdadf102|234|0x15 0|4|libxul.so|nsTableFrame::DisplayGenericTablePart|hg:hg.mozilla.org/mozilla-central:layout/tables/nsTableFrame.cpp:ac93fdadf102|1611|0x16 0|5|libxul.so|nsIFrame::BuildDisplayListForChild|hg:hg.mozilla.org/mozilla-central:layout/generic/nsFrame.cpp:ac93fdadf102|3767|0x17 0|6|libxul.so|nsTableFrame::GenericTraversal|hg:hg.mozilla.org/mozilla-central:layout/tables/nsTableFrame.cpp:ac93fdadf102|1352|0x15 0|7|libxul.so|nsTableFrame::DisplayGenericTablePart|hg:hg.mozilla.org/mozilla-central:layout/tables/nsTableFrame.cpp:ac93fdadf102|1611|0x16 0|8|libxul.so|nsIFrame::BuildDisplayListForChild|hg:hg.mozilla.org/mozilla-central:layout/generic/nsFrame.cpp:ac93fdadf102|3767|0x17 0|9|libxul.so|nsTableWrapperFrame::BuildDisplayListForInnerTable|hg:hg.mozilla.org/mozilla-central:layout/tables/nsTableWrapperFrame.cpp:ac93fdadf102|210|0x14 0|10|libxul.so|nsTableWrapperFrame::BuildDisplayList|hg:hg.mozilla.org/mozilla-central:layout/tables/nsTableWrapperFrame.cpp:ac93fdadf102|178|0x5 0|11|libxul.so|nsIFrame::BuildDisplayListForChild|hg:hg.mozilla.org/mozilla-central:layout/generic/nsFrame.cpp:ac93fdadf102|3767|0x17 0|12|libxul.so|DisplayLine|hg:hg.mozilla.org/mozilla-central:layout/generic/nsBlockFrame.cpp:ac93fdadf102|6660|0x19 0|13|libxul.so|nsBlockFrame::BuildDisplayList|hg:hg.mozilla.org/mozilla-central:layout/generic/nsBlockFrame.cpp:ac93fdadf102|6756|0x38 0|14|libxul.so|nsIFrame::BuildDisplayListForChild|hg:hg.mozilla.org/mozilla-central:layout/generic/nsFrame.cpp:ac93fdadf102|3767|0x17 0|15|libxul.so|mozilla::ScrollFrameHelper::BuildDisplayList|hg:hg.mozilla.org/mozilla-central:layout/generic/nsGfxScrollFrame.cpp:ac93fdadf102|3615|0x1a 0|16|libxul.so|nsIFrame::BuildDisplayListForStackingContext|hg:hg.mozilla.org/mozilla-central:layout/generic/nsFrame.cpp:ac93fdadf102|2986|0x17 0|17|libxul.so|nsIFrame::BuildDisplayListForChild|hg:hg.mozilla.org/mozilla-central:layout/generic/nsFrame.cpp:ac93fdadf102|3701|0x19 0|18|libxul.so|DisplayLine|hg:hg.mozilla.org/mozilla-central:layout/generic/nsBlockFrame.cpp:ac93fdadf102|6660|0x19 0|19|libxul.so|nsBlockFrame::BuildDisplayList|hg:hg.mozilla.org/mozilla-central:layout/generic/nsBlockFrame.cpp:ac93fdadf102|6756|0x38 0|20|libxul.so|nsIFrame::BuildDisplayListForStackingContext|hg:hg.mozilla.org/mozilla-central:layout/generic/nsFrame.cpp:ac93fdadf102|2986|0x17 0|21|libxul.so|nsIFrame::BuildDisplayListForChild|hg:hg.mozilla.org/mozilla-central:layout/generic/nsFrame.cpp:ac93fdadf102|3701|0x19 0|22|libxul.so|nsCanvasFrame::BuildDisplayList|hg:hg.mozilla.org/mozilla-central:layout/generic/nsCanvasFrame.cpp:ac93fdadf102|605|0x1c 0|23|libxul.so|nsIFrame::BuildDisplayListForChild|hg:hg.mozilla.org/mozilla-central:layout/generic/nsFrame.cpp:ac93fdadf102|3767|0x17 0|24|libxul.so|mozilla::ScrollFrameHelper::BuildDisplayList|hg:hg.mozilla.org/mozilla-central:layout/generic/nsGfxScrollFrame.cpp:ac93fdadf102|3615|0x1a 0|25|libxul.so|nsIFrame::BuildDisplayListForChild|hg:hg.mozilla.org/mozilla-central:layout/generic/nsFrame.cpp:ac93fdadf102|3767|0x17 0|26|libxul.so|mozilla::ViewportFrame::BuildDisplayList|hg:hg.mozilla.org/mozilla-central:layout/generic/ViewportFrame.cpp:ac93fdadf102|66|0x11 0|27|libxul.so|nsIFrame::BuildDisplayListForStackingContext|hg:hg.mozilla.org/mozilla-central:layout/generic/nsFrame.cpp:ac93fdadf102|2986|0x17 0|28|libxul.so|nsLayoutUtils::PaintFrame|hg:hg.mozilla.org/mozilla-central:layout/base/nsLayoutUtils.cpp:ac93fdadf102|3835|0x18 0|29|libxul.so|mozilla::PresShell::Paint|hg:hg.mozilla.org/mozilla-central:layout/base/PresShell.cpp:ac93fdadf102|6496|0x17 0|30|libxul.so|nsViewManager::ProcessPendingUpdatesPaint|hg:hg.mozilla.org/mozilla-central:view/nsViewManager.cpp:ac93fdadf102|480|0x12 0|31|libxul.so|nsViewManager::ProcessPendingUpdatesForView|hg:hg.mozilla.org/mozilla-central:view/nsViewManager.cpp:ac93fdadf102|412|0xd 0|32|libxul.so|nsViewManager::ProcessPendingUpdates|hg:hg.mozilla.org/mozilla-central:view/nsViewManager.cpp:ac93fdadf102|1102|0x11 0|33|libxul.so|nsRefreshDriver::Tick|hg:hg.mozilla.org/mozilla-central:layout/base/nsRefreshDriver.cpp:ac93fdadf102|2046|0x8 0|34|libxul.so|mozilla::RefreshDriverTimer::TickRefreshDrivers|hg:hg.mozilla.org/mozilla-central:layout/base/nsRefreshDriver.cpp:ac93fdadf102|306|0xf 0|35|libxul.so|mozilla::RefreshDriverTimer::Tick|hg:hg.mozilla.org/mozilla-central:layout/base/nsRefreshDriver.cpp:ac93fdadf102|328|0x12 0|36|libxul.so|mozilla::VsyncRefreshDriverTimer::RefreshDriverVsyncObserver::TickRefreshDriver|hg:hg.mozilla.org/mozilla-central:layout/base/nsRefreshDriver.cpp:ac93fdadf102|769|0x5 0|37|libxul.so|mozilla::VsyncRefreshDriverTimer::RefreshDriverVsyncObserver::NotifyVsync|hg:hg.mozilla.org/mozilla-central:layout/base/nsRefreshDriver.cpp:ac93fdadf102|583|0xc 0|38|libxul.so|mozilla::layout::VsyncChild::RecvNotify|hg:hg.mozilla.org/mozilla-central:layout/ipc/VsyncChild.cpp:ac93fdadf102|68|0x9 0|39|libxul.so|mozilla::layout::PVsyncChild::OnMessageReceived|s3:gecko-generated-sources:06086093ccb59dd5a99cf8c9f9fb7f4860fd8ddbfd516af5e5b3508be62029679421dcf2abdf6b1c945b6a054050bd403c9574aad49f857cb4a31d3f4cf56b9a/ipc/ipdl/PVsyncChild.cpp:|155|0xf 0|40|libxul.so|mozilla::ipc::MessageChannel::DispatchAsyncMessage|hg:hg.mozilla.org/mozilla-central:ipc/glue/MessageChannel.cpp:ac93fdadf102|2110|0x6 0|41|libxul.so|mozilla::ipc::MessageChannel::DispatchMessage|hg:hg.mozilla.org/mozilla-central:ipc/glue/MessageChannel.cpp:ac93fdadf102|2040|0xb 0|42|libxul.so|mozilla::ipc::MessageChannel::RunMessage|hg:hg.mozilla.org/mozilla-central:ipc/glue/MessageChannel.cpp:ac93fdadf102|1886|0xb 0|43|libxul.so|mozilla::ipc::MessageChannel::MessageTask::Run|hg:hg.mozilla.org/mozilla-central:ipc/glue/MessageChannel.cpp:ac93fdadf102|1919|0xc 0|44|libxul.so|nsThread::ProcessNextEvent|hg:hg.mozilla.org/mozilla-central:xpcom/threads/nsThread.cpp:ac93fdadf102|1039|0x15
Flags: in-testsuite?
[ Triage 2017/02/20: P3 ]
Priority: -- → P3
I saw this assertion when I open https://bugzilla.mozilla.org/attachment.cgi?id=8981269 and scroll the content.
Attached file A backtrace (deleted) —
The stack is bit different from comment 0. In this case, ActiveScrolledRoot::PickDescendant.
(In reply to Hiroyuki Ikezoe (:hiro) from comment #2) > I saw this assertion when I open > https://bugzilla.mozilla.org/attachment.cgi?id=8981269 and scroll the > content. This is wrong! The assertion happens when I open the attachment and open devtools animation inspector.
Blocks: 1298218
This test constructs a frame tree that looks something like this: Viewport < HTMLScroll(1) Canvas Block line Placeholder(2) > FixedList < HTMLScroll(2) // Content > Both scroll frames are active and create ASRs. When we descend into the inner scroll frame, we set the current ASR to nullptr [1], since that's the correct ASR for the containing block. We then create a new ASR for the inner scrollframe that has no ancestor, and our two ASRs are not related (which I believe is correct). nsDisplayListBuilder::mCurrentContainerASR still points to the ASR for the outer scrollframe though, so mCurrentContainerASR/mCurrentActiveScrolledRoot are not related. Then we instantiate an AutoContainerASRTracker, which sets mCurrentContainerASR to the value of mCurrentActiveScrolledRoot, and saves the old value of mCurrentActiveScrolledRoot into mSavedContainerASR. Nothing changes while it's in scope, and then we assert in the destructor, since mCurrentContainerASR and mSavedContainerASR(/mCurrentActiveScrolledRoot) are not related. Any idea what the right solution is for this Markus? [1] https://searchfox.org/mozilla-central/source/layout/generic/nsFrame.cpp#3734
Component: Layout → Layout: Web Painting
Flags: needinfo?(mstange)
(In reply to Matt Woodrow (:mattwoodrow) from comment #5) > When we descend into the inner scroll frame, we set the current ASR to > nullptr [1], since that's the correct ASR for the containing block. We then > create a new ASR for the inner scrollframe that has no ancestor, and our two > ASRs are not related (which I believe is correct). I agree, this part seems correct. > nsDisplayListBuilder::mCurrentContainerASR still points to the ASR for the > outer scrollframe though, This is the bug, I think. mCurrentContainerASR should be nullptr. > Any idea what the right solution is for this Markus? Not sure, I haven't given it much thought yet.
Flags: needinfo?(mstange)
Blocks: 1454206
Markus, this assertion failure has been cropping up in various Android scrolling bugs, such as bug 1454206 and now the site in https://webcompat.com/issues/19116. Any chance of getting this fixed?
Flags: needinfo?(mstange)
Blocks: 1501342
(In reply to Botond Ballo [:botond] from comment #7) > Markus, this assertion failure has been cropping up in various Android > scrolling bugs, such as bug 1454206 and now the site in > https://webcompat.com/issues/19116. Any chance of getting this fixed? And now, on the comments section of the New York Times (bug 1501342).
Blocks: 1493250
There are actually two different assertions with this condition: one in PickAncestor(), and one in PickDescendant(). We've been using this bug for both of them, but they may in fact have different underlying causes.
Depends on: 1511419
No longer blocks: 1501342

(In reply to Markus Stange [:mstange] from comment #6)

nsDisplayListBuilder::mCurrentContainerASR still points to the ASR for the
outer scrollframe though,

This is the bug, I think. mCurrentContainerASR should be nullptr.

This is because of these two lines

https://searchfox.org/mozilla-central/rev/ddd065ed26206d7ded61a4e5a35abb0cd6dbd9bc/layout/painting/nsDisplayList.cpp#438
https://searchfox.org/mozilla-central/rev/ddd065ed26206d7ded61a4e5a35abb0cd6dbd9bc/layout/painting/nsDisplayList.h#1352

If we change them to both to ignore the content clip asr (and hence remove the PickDescendant call) it fixes this bug. I don't quite understand the explanatory comment but this seems like an optimization? Or maybe not.

That change only fails on reftest

https://treeherder.mozilla.org/jobs?repo=try&revision=6634b9f85547c1d1d716d15497148fa4b0b2d7ae

REFTEST TEST-UNEXPECTED-FAIL | layout/reftests/layers/fixed-pos-scrolled-clip-opacity-layerize.html == layout/reftests/layers/fixed-pos-scrolled-clip-opacity-inside-layerize.html | failed reftest-assigned-layer: these elements are assigned to 2 different layers, instead of sharing just one layer: <div class="blueBox" reftest-assigned-layer="page-background">, <div class="absoluteCyanBox" reftest-assigned-layer="page-background">, these elements are assigned to 2 different layers, instead of sharing just one layer: <div class="blueBox" reftest-assigned-layer="page-background">, <div class="absoluteCyanBox" reftest-assigned-layer="page-background">

I'm not necessarily suggested we take that approach just recording what I learned.

Crash Signature: [@ core::option::expect_failed | webrender::spatial_tree::SpatialTree::get_relative_transform] [@ core::option::expect_failed | webrender::spatial_tree::SpatialTree::get_relative_transform_with_face]

The crash frequency increased at the end of February. Glenn, can you check what started this?

Crash Signature: [@ core::option::expect_failed | webrender::spatial_tree::SpatialTree::get_relative_transform] [@ core::option::expect_failed | webrender::spatial_tree::SpatialTree::get_relative_transform_with_face] → [@ core::option::expect_failed | webrender::spatial_tree::SpatialTree::get_relative_transform] [@ core::option::expect_failed | webrender::spatial_tree::SpatialTree::get_relative_transform_with_face]
Flags: needinfo?(gwatson)

Do we have an approximate regression range for when this got worse? Eyeballing it seems like maybe 2021-02-23.

I think it's unlikely it's from that - because backdrop-filter is disabled by default, and only enabled if the user explicitly opts-in via about:config, so I expect that very few users have that enabled, unless some large number of people recently enabled that pref for some reason?

I'm not sure how to find out with any confidence what it's from. Any ideas on how we would normally work out what might have caused something like that?

Unfortunately, although the eventual panic occurs in WR, it looks like this is probably from an invalid display list that Gecko is supplying, due to the assertion failure in DL building, which I don't have a good understanding of.

Flags: needinfo?(gwatson)
Testcase found while fuzzing mozilla-central rev f4ad9b76e5f8 (built with: --enable-debug --enable-fuzzing). Testcase can be reproduced using the following commands: $ pip install fuzzfetch grizzly-framework $ python -m fuzzfetch --build f4ad9b76e5f8 --debug --fuzzing -n firefox $ python -m grizzly.replay ./firefox/firefox testcase.zip
Attached file Detailed Crash Information (deleted) —
Attached file Testcase (deleted) —
Attachment #9238928 - Attachment description: Testcase for comment 8 → Testcase

A Pernosco session is available here: https://pernos.co/debug/2ZzYXSnoJzjd9AE0875Y3w/index.html

It was created using the test case attached in comment 18.

(In reply to Jason Kratzer [:jkratzer] from comment #16)

Testcase found while fuzzing mozilla-central rev f4ad9b76e5f8 (built with:
--enable-debug --enable-fuzzing).

Testcase can be reproduced using the following commands:

$ pip install fuzzfetch grizzly-framework
$ python -m fuzzfetch --build f4ad9b76e5f8 --debug --fuzzing -n firefox
$ python -m grizzly.replay ./firefox/firefox testcase.zip

Does this mean reproducing the crash requires more than just loading the testcase in the browser? If so, what else (in terms of interactions with the browser) does this replay script do?

(In reply to Botond Ballo [:botond] from comment #21)

Does this mean reproducing the crash requires more than just loading the testcase in the browser? If so, what else (in terms of interactions with the browser) does this replay script do?

No. Grizzly.replay is just used to automate launching the browser with the prefs included in testcase.zip and opening the testcase.

Webcompat Priority: --- → ?
Webcompat Priority: ? → ---
Severity: normal → S3

I think we have a workaround for this these days.

Flags: needinfo?(mstange.moz)
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: