I hit this crash when loading Epiphany's new tab page yesterday. We have 24 reports of it:
Truncated backtrace:
Thread no. 1 (10 frames)
#0 WebCore::Animation::animationsMatch at /usr/src/debug/webkitgtk-2.14.1/Source/WebCore/platform/animation/Animation.cpp:138
#1 WebCore::Animation::operator== at /usr/src/debug/webkitgtk-2.14.1/Source/WebCore/platform/animation/Animation.h:168
#2 WebCore::Animation::operator!= at /usr/src/debug/webkitgtk-2.14.1/Source/WebCore/platform/animation/Animation.h:169
#3 WebCore::AnimationList::operator== at /usr/src/debug/webkitgtk-2.14.1/Source/WebCore/platform/animation/AnimationList.cpp:59
#4 WTF::arePointingToEqualData<std::unique_ptr<WebCore::AnimationList, std::default_delete<WebCore::AnimationList> > > at /usr/src/debug/webkitgtk-2.14.1/Source/WTF/wtf/PointerComparison.h:33
#5 WebCore::StyleRareNonInheritedData::operator== at /usr/src/debug/webkitgtk-2.14.1/Source/WebCore/rendering/style/StyleRareNonInheritedData.cpp:258
#6 WebCore::DataRef<WebCore::StyleRareNonInheritedData>::operator== at /usr/src/debug/webkitgtk-2.14.1/Source/WebCore/rendering/style/DataRef.h:51
#7 WebCore::RenderStyle::operator== at /usr/src/debug/webkitgtk-2.14.1/Source/WebCore/rendering/style/RenderStyle.cpp:305
#8 WebCore::RenderStyle::operator!= at /usr/src/debug/webkitgtk-2.14.1/Source/WebCore/rendering/style/RenderStyle.h:549
#9 WebCore::Style::determineChange at /usr/src/debug/webkitgtk-2.14.1/Source/WebCore/style/StyleChange.cpp:63
There is a detailed backtrace attached to comment #1 in the downstream bug.
(In reply to comment #0)
> There is a detailed backtrace attached to comment #1 in the downstream bug.
In particular:
Program terminated with signal SIGSEGV, Segmentation fault.
#0 0x00007fd56123212b in WebCore::Animation::animationsMatch (this=0x7fd54b2b1d80, other=..., matchPlayStates=matchPlayStates@entry=true) at /usr/src/debug/webkitgtk-2.14.1/Source/WebCore/platform/animation/Animation.cpp:138
138 && *(m_timingFunction.get()) == *(other.m_timingFunction.get())
(In reply to comment #2)
> Can you attach the HTML/CSS that triggers this?
I can attach the HTML/CSS generated by my overview page (which could be slightly different from what it was yesterday if my top 10 visited sites have changed since yesterday; possible since I've cleared my history recently), but it is some rare race and definitely not a reliable reproducer.
(In reply to comment #6)
> Can you reproduce the crash with this HTML and CSS?
No, I do not have a reproducer. I just happen to remember it crashed yesterday displaying about:overview (which does not even contain any animations).
FWIW there is a FIXME in TreeResolver::createAnimatedElementUpdate one line beneath the crash:
update.change = determineChange(rendererToUpdate->style(), *animatedStyle);
// If animation forces render tree reconstruction pass the original style. The animation will be applied on renderer construction.
// FIXME: We should always use the animated style here.
update.style = update.change == Detach ? WTFMove(newStyle) : WTFMove(animatedStyle);
But that looks probably unrelated.
WebCore::Animation is a RefCounted object that is thread-unsafe.
TextureMapperAnimation was shared between the main thread and
ThreadedCompositor thread. WebCore::Animation object should be
cloned and TextureMapperAnimation should have an isoleted copy of
WebCore::Animation. Zan's patch (Bug 166923 comment 1) was aiming
that.
r248406 (Bug 200533) changed TextureMapperAnimation to have
RefPtr<TimingFunction> instead of RefPtr<WebCore::Animation>, and
call TimingFunction::clone(). I think this crash was fixed by
r248406.
2016-11-18 08:34 PST, Michael Catanzaro
2016-11-18 08:35 PST, Michael Catanzaro
2019-01-25 11:46 PST, Michael Catanzaro