Closed Bug 1802386 Opened 2 years ago Closed 2 years ago

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)

defect

Tracking

()

VERIFIED FIXED
110 Branch
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)

Attached file testcase.html (deleted) —

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)
Flags: in-testsuite?
Attached file prefs.js (deleted) —

prefs.js file for bugmon

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.

Blocks: a11y-ctw
Severity: -- → S2
Flags: needinfo?(mreschenberg)
Priority: -- → P1
Whiteboard: [ctw-m4]

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

Keywords: regression
Whiteboard: [ctw-m4] → [bugmon:bisected,confirmed]

Looks like bugmon wiped the whiteboard.

Flags: needinfo?(jkratzer)
Whiteboard: [bugmon:bisected,confirmed] → [bugmon:bisected,confirmed][ctw-m4]

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.

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.

Regressed by: 1726227
No longer regressed by: 1796734

(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.

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.

Flags: needinfo?(twsmith)
Flags: needinfo?(jkratzer)

yes, that'd be awesome :) thanks!

Flags: needinfo?(mreschenberg)
Whiteboard: [bugmon:bisected,confirmed][ctw-m4] → [bugmon:bisected,confirmed,pernosco][ctw-m4]

Successfully recorded a pernosco session. A link to the pernosco-session will be added here shortly.

Whiteboard: [bugmon:bisected,confirmed,pernosco][ctw-m4] → [bugmon:bisected,confirmed][ctw-m4]

A pernosco session for this bug can be found here.

(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.

ni?me to come back to this

Flags: needinfo?(twsmith) → needinfo?(mreschenberg)
Assignee: nobody → mreschenberg
Flags: needinfo?(mreschenberg)
Attachment #9307430 - Attachment description: WIP: Bug 1802386: If we can't find a prescontext or the root prescontext, bail out of WillRefresh r?Jamie → Bug 1802386: If we can't find a PresContext or the root PresContext, bail out of WillRefresh r?Jamie

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

Pushed by mreschenberg@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/4734e5a8ad79 If we can't find a PresContext or the root PresContext, bail out of WillRefresh r=Jamie
Status: NEW → RESOLVED
Closed: 2 years ago
Resolution: --- → FIXED
Target Milestone: --- → 110 Branch

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 to wontfix.

For more information, please visit auto_nag documentation.

Flags: needinfo?(mreschenberg)
Flags: needinfo?(mreschenberg)

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.

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.

Status: RESOLVED → VERIFIED
Keywords: bugmon
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: