Hit MOZ_CRASH(trying to get the offset between frames in different document hierarchies?) at /builds/worker/checkouts/gecko/layout/generic/nsIFrame.cpp:7031
Categories
(Core :: Disability Access APIs, defect, P1)
Tracking
()
Tracking | Status | |
---|---|---|
firefox-esr102 | --- | unaffected |
firefox107 | --- | unaffected |
firefox108 | --- | unaffected |
firefox109 | --- | wontfix |
firefox110 | --- | verified |
People
(Reporter: tsmith, Assigned: morgan)
References
(Blocks 2 open bugs, Regression)
Details
(Keywords: assertion, regression, testcase, Whiteboard: [bugmon:bisected,confirmed][ctw-m4])
Attachments
(3 files)
(deleted),
text/html
|
Details | |
(deleted),
application/x-javascript
|
Details | |
Bug 1802386: If we can't find a PresContext or the root PresContext, bail out of WillRefresh r?Jamie
(deleted),
text/x-phabricator-request
|
Details |
Found while fuzzing m-c 20221116-efbd04cb0748 (--enable-debug --enable-fuzzing)
To reproduce via Grizzly Replay:
$ pip install fuzzfetch grizzly-framework
$ python -m fuzzfetch -d --fuzzing -n firefox
$ python -m grizzly.replay ./firefox/firefox testcase.html
Hit MOZ_CRASH(trying to get the offset between frames in different document hierarchies?) at /builds/worker/checkouts/gecko/layout/generic/nsIFrame.cpp:7031
#0 0x7f87257ca3c7 in nsIFrame::GetOffsetToCrossDoc(nsIFrame const*, int) const /gecko/layout/generic/nsIFrame.cpp:7029:5
#1 0x7f87255d7942 in BoxToRect::AddBox(nsIFrame*) /gecko/layout/base/nsLayoutUtils.cpp:3713:21
#2 0x7f872558627a in GetAllInFlowBoxes /gecko/layout/base/nsLayoutUtils.cpp:3613:5
#3 0x7f872558627a in GetAllInFlowRects /gecko/layout/base/nsLayoutUtils.cpp:3770:3
#4 0x7f872558627a in nsLayoutUtils::GetAllInFlowRectsUnion(nsIFrame*, nsIFrame const*, unsigned int) /gecko/layout/base/nsLayoutUtils.cpp:3810:3
#5 0x7f8729125352 in mozilla::a11y::LocalAccessible::ParentRelativeBounds() /gecko/accessible/generic/LocalAccessible.cpp:645:21
#6 0x7f8729103401 in mozilla::a11y::LocalAccessible::BundleFieldsForCache(unsigned long, mozilla::a11y::CacheUpdateType) /gecko/accessible/generic/LocalAccessible.cpp:3291:28
#7 0x7f87290facfe in mozilla::a11y::LocalAccessible::SendCache(unsigned long, mozilla::a11y::CacheUpdateType) /gecko/accessible/generic/LocalAccessible.cpp:3098:7
#8 0x7f8729109930 in mozilla::a11y::DocAccessible::DoInitialUpdate() /gecko/accessible/generic/DocAccessible.cpp:1648:9
#9 0x7f87290761e8 in mozilla::a11y::NotificationController::WillRefresh(mozilla::TimeStamp) /gecko/accessible/base/NotificationController.cpp:671:16
#10 0x7f8725402fc5 in nsRefreshDriver::Tick(mozilla::layers::BaseTransactionId<mozilla::VsyncIdType>, mozilla::TimeStamp, nsRefreshDriver::IsExtraTick) /gecko/layout/base/nsRefreshDriver.cpp:2525:12
#11 0x7f8725411526 in TickDriver /gecko/layout/base/nsRefreshDriver.cpp:375:13
#12 0x7f8725411526 in mozilla::RefreshDriverTimer::TickRefreshDrivers(mozilla::layers::BaseTransactionId<mozilla::VsyncIdType>, mozilla::TimeStamp, nsTArray<RefPtr<nsRefreshDriver>>&) /gecko/layout/base/nsRefreshDriver.cpp:353:7
#13 0x7f872541128e in mozilla::RefreshDriverTimer::Tick(mozilla::layers::BaseTransactionId<mozilla::VsyncIdType>, mozilla::TimeStamp) /gecko/layout/base/nsRefreshDriver.cpp:369:5
#14 0x7f8725411015 in mozilla::VsyncRefreshDriverTimer::RunRefreshDrivers(mozilla::layers::BaseTransactionId<mozilla::VsyncIdType>, mozilla::TimeStamp) /gecko/layout/base/nsRefreshDriver.cpp:913:5
#15 0x7f87254102af in mozilla::VsyncRefreshDriverTimer::TickRefreshDriver(mozilla::layers::BaseTransactionId<mozilla::VsyncIdType>, mozilla::TimeStamp) /gecko/layout/base/nsRefreshDriver.cpp:827:5
#16 0x7f872540f4f1 in mozilla::VsyncRefreshDriverTimer::NotifyVsyncOnMainThread(mozilla::VsyncEvent const&) /gecko/layout/base/nsRefreshDriver.cpp:748:5
#17 0x7f872540ed0b in mozilla::VsyncRefreshDriverTimer::RefreshDriverVsyncObserver::NotifyVsyncTimerOnMainThread() /gecko/layout/base/nsRefreshDriver.cpp:594:14
#18 0x7f872540e8a8 in mozilla::VsyncRefreshDriverTimer::RefreshDriverVsyncObserver::NotifyVsync(mozilla::VsyncEvent const&) /gecko/layout/base/nsRefreshDriver.cpp:551:9
#19 0x7f87240681ec in mozilla::dom::VsyncMainChild::RecvNotify(mozilla::VsyncEvent const&, float const&) /gecko/dom/ipc/VsyncMainChild.cpp:68:15
#20 0x7f87244b2c4f in mozilla::dom::PVsyncChild::OnMessageReceived(IPC::Message const&) /builds/worker/workspace/obj-build/ipc/ipdl/PVsyncChild.cpp:220:78
#21 0x7f871dde5f26 in mozilla::ipc::PBackgroundChild::OnMessageReceived(IPC::Message const&) /builds/worker/workspace/obj-build/ipc/ipdl/PBackgroundChild.cpp:6306:32
#22 0x7f871dd4eb09 in mozilla::ipc::MessageChannel::DispatchAsyncMessage(mozilla::ipc::ActorLifecycleProxy*, IPC::Message const&) /gecko/ipc/glue/MessageChannel.cpp:1756:25
#23 0x7f871dd4bbff in mozilla::ipc::MessageChannel::DispatchMessage(mozilla::ipc::ActorLifecycleProxy*, mozilla::UniquePtr<IPC::Message, mozilla::DefaultDelete<IPC::Message>>) /gecko/ipc/glue/MessageChannel.cpp:1681:9
#24 0x7f871dd4c82e in mozilla::ipc::MessageChannel::RunMessage(mozilla::ipc::ActorLifecycleProxy*, mozilla::ipc::MessageChannel::MessageTask&) /gecko/ipc/glue/MessageChannel.cpp:1481:3
#25 0x7f871dd4da5e in mozilla::ipc::MessageChannel::MessageTask::Run() /gecko/ipc/glue/MessageChannel.cpp:1579:14
#26 0x7f871c5ccd79 in mozilla::RunnableTask::Run() /gecko/xpcom/threads/TaskController.cpp:538:16
#27 0x7f871c5c3e37 in mozilla::TaskController::DoExecuteNextTaskOnlyMainThreadInternal(mozilla::detail::BaseAutoLock<mozilla::Mutex&> const&) /gecko/xpcom/threads/TaskController.cpp:851:26
#28 0x7f871c5c10b8 in mozilla::TaskController::ExecuteNextTaskOnlyMainThreadInternal(mozilla::detail::BaseAutoLock<mozilla::Mutex&> const&) /gecko/xpcom/threads/TaskController.cpp:683:15
#29 0x7f871c5c17e0 in mozilla::TaskController::ProcessPendingMTTask(bool) /gecko/xpcom/threads/TaskController.cpp:461:36
#30 0x7f871c5d2e81 in operator() /gecko/xpcom/threads/TaskController.cpp:187:37
#31 0x7f871c5d2e81 in mozilla::detail::RunnableFunction<mozilla::TaskController::InitializeInternal()::$_2>::Run() /builds/worker/workspace/obj-build/dist/include/nsThreadUtils.h:546:5
#32 0x7f871c5f60b0 in nsThread::ProcessNextEvent(bool, bool*) /gecko/xpcom/threads/nsThread.cpp:1204:16
#33 0x7f871c600844 in NS_ProcessNextEvent(nsIThread*, bool) /gecko/xpcom/threads/nsThreadUtils.cpp:474:10
#34 0x7f871dd562fe in mozilla::ipc::MessagePump::Run(base::MessagePump::Delegate*) /gecko/ipc/glue/MessagePump.cpp:85:21
#35 0x7f871dbda2a7 in RunInternal /gecko/ipc/chromium/src/base/message_loop.cc:381:10
#36 0x7f871dbda2a7 in RunHandler /gecko/ipc/chromium/src/base/message_loop.cc:374:3
#37 0x7f871dbda2a7 in MessageLoop::Run() /gecko/ipc/chromium/src/base/message_loop.cc:356:3
#38 0x7f8724e295c9 in nsBaseAppShell::Run() /gecko/widget/nsBaseAppShell.cpp:150:27
#39 0x7f8729d80d28 in XRE_RunAppShell() /gecko/toolkit/xre/nsEmbedFunctions.cpp:884:20
#40 0x7f871dbda2a7 in RunInternal /gecko/ipc/chromium/src/base/message_loop.cc:381:10
#41 0x7f871dbda2a7 in RunHandler /gecko/ipc/chromium/src/base/message_loop.cc:374:3
#42 0x7f871dbda2a7 in MessageLoop::Run() /gecko/ipc/chromium/src/base/message_loop.cc:356:3
#43 0x7f8729d7fcf5 in XRE_InitChildProcess(int, char**, XREChildData const*) /gecko/toolkit/xre/nsEmbedFunctions.cpp:743:34
#44 0x5608592d62d4 in content_process_main(mozilla::Bootstrap*, int, char**) /gecko/browser/app/../../ipc/contentproc/plugin-container.cpp:57:28
#45 0x5608592d6797 in main /gecko/browser/app/nsBrowserApp.cpp:359:18
#46 0x7f873e82f082 in __libc_start_main /build/glibc-SzIz7B/glibc-2.31/csu/../csu/libc-start.c:308:16
#47 0x560859214d58 in _start (/home/worker/builds/m-c-20221116182402-fuzzing-asan-opt/firefox+0x111d58) (BuildId: 9d1e28432ab322f1cc7ea87bf9dd7bbbb166692e)
Reporter | ||
Comment 1•2 years ago
|
||
prefs.js file for bugmon
Comment 2•2 years ago
|
||
Morgan, would you mind looking into this? Disclaimer: i haven't looked into it myself one bit other than to realise it's related to ParentRelativeBounds.
Marking s2 because this causes an immediate tab crash.
Comment 3•2 years ago
|
||
Verified bug as reproducible on mozilla-central 20221124212638-e12f31999d33.
The bug appears to have been introduced in the following build range:
Start: 2d625e5d6ff86fda6d83464bb315478f94afc577 (20221114233128)
End: 1adc82d1eb960a8a6aac68b9abceaac3fd491abb (20221115021943)
Pushlog: https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=2d625e5d6ff86fda6d83464bb315478f94afc577&tochange=1adc82d1eb960a8a6aac68b9abceaac3fd491abb
Reporter | ||
Comment 4•2 years ago
|
||
Looks like bugmon wiped the whiteboard.
Comment 5•2 years ago
|
||
I guess we're walking across document boundaries in LocalAccessible::FindNearestAccessibleAncestorFrame. But actually, I'm puzzled as to how we're not always doing that when called on an in-process iframe document itself. Unless we're dealing with a tab document or an OOP iframe, we hit this loop, which starts at mParent. For an in-process iframe DocAccessible, mParent will be the iframe, which is in a different document.
Updated•2 years ago
|
Comment 6•2 years ago
|
||
I don't think the regressing bug is correct here. Enabling CTW made this show up, but I couldn't tell you specifically which bug introduced the crash. Maybe bug 1726227.
Updated•2 years ago
|
Updated•2 years ago
|
Comment 7•2 years ago
|
||
(In reply to James Teh [:Jamie] from comment #5)
I guess we're walking across document boundaries in LocalAccessible::FindNearestAccessibleAncestorFrame. But actually, I'm puzzled as to how we're not always doing that when called on an in-process iframe document itself. Unless we're dealing with a tab document or an OOP iframe, we hit this loop, which starts at mParent. For an in-process iframe DocAccessible, mParent will be the iframe, which is in a different document.
The assert is about being in the same document hierarchy (meaning the tree of iframes that are reachable from each other), not the same document.
Since the testcase doesn't seem too complicated I'm guessing the frequent reloading means that we are running this code on a frame tree that has been disconnected from the document hierarchy maybe?
I wasn't able to reproduce using the testcase so I can't say more.
Comment 8•2 years ago
|
||
Tyson pinged me directly asking if a Pernosco session would help. It won't help me, but I'm guessing it might help you, Morgan?
Tyson, we'll take you up on that offer of a Pernosco session please.
Updated•2 years ago
|
Updated•2 years ago
|
Comment 10•2 years ago
|
||
Successfully recorded a pernosco session. A link to the pernosco-session will be added here shortly.
Comment hidden (obsolete) |
Comment 12•2 years ago
|
||
A pernosco session for this bug can be found here.
Comment 13•2 years ago
|
||
(In reply to Timothy Nikkel (:tnikkel) from comment #7)
Since the testcase doesn't seem too complicated I'm guessing the frequent reloading means that we are running this code on a frame tree that has been disconnected from the document hierarchy maybe?
Indeed, looking at the pernosco the frame is inside the iframe/embed for the uri "data:audio/mp3;base64,//", and it does not have a parent pres context, so it is not connected to it's parent prescontext, so GetRootPresContext returns null (can't reach a root prescontext). When this happens the best thing to do is nothing, the frames aren't being rendered as they aren't connected to a rendered document tree.
Assignee | ||
Comment 14•2 years ago
|
||
ni?me to come back to this
Assignee | ||
Updated•2 years ago
|
Assignee | ||
Comment 15•2 years ago
|
||
Updated•2 years ago
|
Comment 16•2 years ago
|
||
Set release status flags based on info from the regressing bug 1726227
Comment 17•2 years ago
|
||
Comment 18•2 years ago
|
||
bugherder |
Comment 19•2 years ago
|
||
The patch landed in nightly and beta is affected.
:morgan, is this bug important enough to require an uplift?
- If yes, please nominate the patch for beta approval.
- If no, please set
status-firefox109
towontfix
.
For more information, please visit auto_nag documentation.
Assignee | ||
Updated•2 years ago
|
Assignee | ||
Updated•2 years ago
|
Assignee | ||
Comment 20•2 years ago
|
||
Not requesting uplift for this, I think it should ride the trains, since (a) this is a fuzzing failure and we haven't gotten any in-the-wild reports to match it and (b) while the change I made was for CtW, it has the ability to affect our non-caching architecture. We haven't experienced this crash there, so there isn't urgency on that front.
Comment 21•2 years ago
|
||
Verified bug as fixed on rev mozilla-central 20221215092759-061ba69417eb.
Removing bugmon keyword as no further action possible. Please review the bug and re-add the keyword for further analysis.
Description
•