1453601 - Crash in TransformGfxRectToAncestor

Status: RESOLVED WORKSFORME

(Core :: Web Painting, defect)

Description

[[:philipp]]

This bug was filed from the Socorro interface and is
report bp-1ee879a6-87e9-48f2-84c2-8372f0180412.
=============================================================

Top 10 frames of crashing thread:

0 xul.dll TransformGfxRectToAncestor layout/base/nsLayoutUtils.cpp:3082
1 xul.dll nsLayoutUtils::TransformFrameRectToAncestor layout/base/nsLayoutUtils.cpp:3155
2 xul.dll ProcessFrame layout/painting/RetainedDisplayListBuilder.cpp:814
3 xul.dll ProcessFrame layout/painting/RetainedDisplayListBuilder.cpp:808
4 xul.dll RetainedDisplayListBuilder::ComputeRebuildRegion layout/painting/RetainedDisplayListBuilder.cpp:993
5 xul.dll RetainedDisplayListBuilder::AttemptPartialUpdate layout/painting/RetainedDisplayListBuilder.cpp:1131
6 xul.dll nsLayoutUtils::PaintFrame layout/base/nsLayoutUtils.cpp:3868
7 xul.dll mozilla::PresShell::Paint layout/base/PresShell.cpp:6435
8 xul.dll nsViewManager::ProcessPendingUpdatesPaint view/nsViewManager.cpp:480
9 xul.dll nsViewManager::ProcessPendingUpdatesForView view/nsViewManager.cpp:412

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

this crash signature is regressing across platforms in the firefox 60 beta cycle - nearly always in the content process.

the same signature got already fixed once before in bug 1427476 - when looking at the crash pattern in nightly builds, this was successful as the crashes have stopped in the builds after the patch has landed.

however the crash re-emerged on 59.0a1 build 20180119220144, which would coincide with bug 1428993 which may have regressed the crash again (tentatively marking this bug as blocking 1428993).

there were a handful of crashes with this signature at the start of the 61.0a1 cycle as well, but something seems to have addressed them in the meantime...

Comment 1

[Matt Woodrow (:mattwoodrow)]

Low volume, so not super concerned right now.

I had a look at the reports, haven't been able to reproduce a crash from the URLs there yet.

Do you have any idea when this might have got fixed in 61? I can't find any relevant changed code there.

Miko, this looks like TransformGfxRectToAncestor has walked up the frame tree until aOutAncestor == nullptr, which suggests that our aStopAtAncestor wasn't actually an ancestor. This is within the recursive call to ProcessFrame for the placeholder.

I can't see how that's possible though, since we chose it using nsLayoutUtils::FindNearestCommonAncestorFrame which walks up the tree in the exact same way..

Comment 2

[Julien Cristau [:jcristau]]

RDL was disabled for 60 in bug 1454509

Comment 3

[Tyson Smith [:tsmith]]

Attachment: testcase.html

Found a testcase. I assume this is the same crash.
Reduced with m-c:
BuildID=20180601094245
SourceStamp=9900cebb1f9000bd05731ba67736b7c51f7eb812

==52495==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000020 (pc 0x7fa163012859 bp 0x7ffd028e4060 sp 0x7ffd028e3d60 T0)
==52495==The signal is caused by a READ memory access.
==52495==Hint: address points to the zero page.
    #0 0x7fa163012858 in get src/obj-firefox/dist/include/mozilla/RefPtr.h:296:27
    #1 0x7fa163012858 in operator mozilla::ComputedStyle * src/obj-firefox/dist/include/mozilla/RefPtr.h:309
    #2 0x7fa163012858 in Style src/layout/generic/nsIFrame.h:783
    #3 0x7fa163012858 in PresContext src/layout/generic/nsIFrame.h:628
    #4 0x7fa163012858 in TransformGfxRectToAncestor(nsIFrame*, mozilla::gfx::RectTyped<mozilla::gfx::UnknownUnits, float> const&, nsIFrame const*, bool*, mozilla::Maybe<mozilla::gfx::Matrix4x4TypedFlagged<mozilla::gfx::UnknownUnits, mozilla::gfx::UnknownUnits> >*, bool, nsIFrame**) src/layout/base/nsLayoutUtils.cpp:2909
    #5 0x7fa163011b30 in nsLayoutUtils::TransformFrameRectToAncestor(nsIFrame*, nsRect const&, nsIFrame const*, bool*, mozilla::Maybe<mozilla::gfx::Matrix4x4TypedFlagged<mozilla::gfx::UnknownUnits, mozilla::gfx::UnknownUnits> >*, bool, nsIFrame**) src/layout/base/nsLayoutUtils.cpp:2982:14
    #6 0x7fa163873ba1 in ProcessFrameInternal(nsIFrame*, nsDisplayListBuilder&, AnimatedGeometryRoot**, nsRect&, nsIFrame*, nsTArray<nsIFrame*>&, bool) src/layout/painting/RetainedDisplayListBuilder.cpp:748:17
    #7 0x7fa163874334 in ProcessFrameInternal(nsIFrame*, nsDisplayListBuilder&, AnimatedGeometryRoot**, nsRect&, nsIFrame*, nsTArray<nsIFrame*>&, bool) src/layout/painting/RetainedDisplayListBuilder.cpp:742:7
    #8 0x7fa163872882 in RetainedDisplayListBuilder::ProcessFrame(nsIFrame*, nsDisplayListBuilder&, nsIFrame*, nsTArray<nsIFrame*>&, bool, nsRect*, AnimatedGeometryRoot**) src/layout/painting/RetainedDisplayListBuilder.cpp:899:3
    #9 0x7fa163876888 in RetainedDisplayListBuilder::ComputeRebuildRegion(nsTArray<nsIFrame*>&, nsRect*, AnimatedGeometryRoot**, nsTArray<nsIFrame*>&) src/layout/painting/RetainedDisplayListBuilder.cpp:1007:10
    #10 0x7fa163877dc8 in RetainedDisplayListBuilder::AttemptPartialUpdate(unsigned int, mozilla::DisplayListChecker*) src/layout/painting/RetainedDisplayListBuilder.cpp:1141:8
    #11 0x7fa16301d11b in nsLayoutUtils::PaintFrame(gfxContext*, nsIFrame*, nsRegion const&, unsigned int, nsDisplayListBuilderMode, nsLayoutUtils::PaintFrameFlags) src/layout/base/nsLayoutUtils.cpp:3695:40
    #12 0x7fa162f10587 in mozilla::PresShell::Paint(nsView*, nsRegion const&, unsigned int) src/layout/base/PresShell.cpp:6314:5
    #13 0x7fa1628a328a in nsViewManager::ProcessPendingUpdatesPaint(nsIWidget*) src/view/nsViewManager.cpp:480:19
    #14 0x7fa1628a208c in nsViewManager::ProcessPendingUpdatesForView(nsView*, bool) src/view/nsViewManager.cpp:412:33
    #15 0x7fa1628a76e6 in nsViewManager::ProcessPendingUpdates() src/view/nsViewManager.cpp:1102:5
    #16 0x7fa162e89e95 in nsRefreshDriver::Tick(long, mozilla::TimeStamp) src/layout/base/nsRefreshDriver.cpp:2039:11
    #17 0x7fa162e96c6b in TickDriver src/layout/base/nsRefreshDriver.cpp:328:13
    #18 0x7fa162e96c6b in mozilla::RefreshDriverTimer::TickRefreshDrivers(long, mozilla::TimeStamp, nsTArray<RefPtr<nsRefreshDriver> >&) src/layout/base/nsRefreshDriver.cpp:301
    #19 0x7fa162e96849 in mozilla::RefreshDriverTimer::Tick(long, mozilla::TimeStamp) src/layout/base/nsRefreshDriver.cpp:320:5
    #20 0x7fa162e9938e in RunRefreshDrivers src/layout/base/nsRefreshDriver.cpp:760:5
    #21 0x7fa162e9938e in mozilla::VsyncRefreshDriverTimer::RefreshDriverVsyncObserver::TickRefreshDriver(mozilla::TimeStamp) src/layout/base/nsRefreshDriver.cpp:673
    #22 0x7fa162e98f8e in mozilla::VsyncRefreshDriverTimer::RefreshDriverVsyncObserver::NotifyVsync(mozilla::TimeStamp) src/layout/base/nsRefreshDriver.cpp:574:9
    #23 0x7fa163751f7f in mozilla::layout::VsyncChild::RecvNotify(mozilla::TimeStamp const&) src/layout/ipc/VsyncChild.cpp:68:16
    #24 0x7fa15c4ed1f4 in mozilla::layout::PVsyncChild::OnMessageReceived(IPC::Message const&) src/obj-firefox/ipc/ipdl/PVsyncChild.cpp:167:20
    #25 0x7fa15c3c53d3 in mozilla::ipc::PBackgroundChild::OnMessageReceived(IPC::Message const&) src/obj-firefox/ipc/ipdl/PBackgroundChild.cpp:1988:28
    #26 0x7fa15bf313fe in mozilla::ipc::MessageChannel::DispatchAsyncMessage(IPC::Message const&) src/ipc/glue/MessageChannel.cpp:2136:25
    #27 0x7fa15bf2e342 in mozilla::ipc::MessageChannel::DispatchMessage(IPC::Message&&) src/ipc/glue/MessageChannel.cpp:2066:17
    #28 0x7fa15bf2fb7c in mozilla::ipc::MessageChannel::RunMessage(mozilla::ipc::MessageChannel::MessageTask&) src/ipc/glue/MessageChannel.cpp:1912:5
    #29 0x7fa15bf301d8 in mozilla::ipc::MessageChannel::MessageTask::Run() src/ipc/glue/MessageChannel.cpp:1945:15
    #30 0x7fa15b03bb76 in nsThread::ProcessNextEvent(bool, bool*) src/xpcom/threads/nsThread.cpp:1088:14
    #31 0x7fa15b057ab0 in NS_ProcessNextEvent(nsIThread*, bool) src/xpcom/threads/nsThreadUtils.cpp:519:10
    #32 0x7fa15bf39086 in mozilla::ipc::MessagePump::Run(base::MessagePump::Delegate*) src/ipc/glue/MessagePump.cpp:125:5
    #33 0x7fa15be8ff49 in RunInternal src/ipc/chromium/src/base/message_loop.cc:326:10
    #34 0x7fa15be8ff49 in RunHandler src/ipc/chromium/src/base/message_loop.cc:319
    #35 0x7fa15be8ff49 in MessageLoop::Run() src/ipc/chromium/src/base/message_loop.cc:299
    #36 0x7fa162930eda in nsBaseAppShell::Run() src/widget/nsBaseAppShell.cpp:157:27
    #37 0x7fa166baecab in XRE_RunAppShell() src/toolkit/xre/nsEmbedFunctions.cpp:893:22
    #38 0x7fa15be8ff49 in RunInternal src/ipc/chromium/src/base/message_loop.cc:326:10
    #39 0x7fa15be8ff49 in RunHandler src/ipc/chromium/src/base/message_loop.cc:319
    #40 0x7fa15be8ff49 in MessageLoop::Run() src/ipc/chromium/src/base/message_loop.cc:299
    #41 0x7fa166bae670 in XRE_InitChildProcess(int, char**, XREChildData const*) src/toolkit/xre/nsEmbedFunctions.cpp:719:34
    #42 0x4f1875 in content_process_main src/browser/app/../../ipc/contentproc/plugin-container.cpp:50:30
    #43 0x4f1875 in main src/browser/app/nsBrowserApp.cpp:282
    #44 0x7fa17a81182f in __libc_start_main /build/glibc-Cl5G7W/glibc-2.23/csu/../csu/libc-start.c:291
    #45 0x420f48 in _start (firefox+0x420f48)

Comment 4

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

Most of these crashes are wildptr reads, writes, execs, stack overruns - take your pick.  Would be Sec-high -- but only for 59 with RDL (there are maybe 2 or 3 crashes total in 60 beta 10-ish with wildptrs, but it's not clear they're real (not bit-flips or other things).  In 60 and later these seem to be virtually all nullptr crashes.  So still an issue, maybe, but only ~4 in 61bN, and none in 62 (though it's low-volume).

Seems RDL-related.

Hiding because of 59, but this may just go away.

Matt - given it's only sec for 59 and rdl enabled, should we un-hide this?  We still probably want to fix the nullptr crashes in any case, if those have not also gone away.

Comment 5

[Matt Woodrow (:mattwoodrow)]

(In reply to Randell Jesup [:jesup] from comment #4)
> Most of these crashes are wildptr reads, writes, execs, stack overruns -
> take your pick.  Would be Sec-high -- but only for 59 with RDL (there are
> maybe 2 or 3 crashes total in 60 beta 10-ish with wildptrs, but it's not
> clear they're real (not bit-flips or other things).  In 60 and later these
> seem to be virtually all nullptr crashes.  So still an issue, maybe, but
> only ~4 in 61bN, and none in 62 (though it's low-volume).
> 
> Seems RDL-related.
> 
> Hiding because of 59, but this may just go away.
> 
> Matt - given it's only sec for 59 and rdl enabled, should we un-hide this? 
> We still probably want to fix the nullptr crashes in any case, if those have
> not also gone away.

I think we're fine to un-hide, RDL is disabled by default on all versions 60 and earlier.

Comment 6

[Matt Woodrow (:mattwoodrow)]

I'm not able to reproduce the nullptr crash either, any ideas Tyson?

Comment 7

[Tyson Smith [:tsmith]]

I cannot reproduce with m-c:
BuildID=20180606093723
SourceStamp=cec4a3cecc29ff97860198969b6fdff24b9e93bb