1607536 - Crash in [@ core::ptr::real_drop_in_place | core::ptr::real_drop_in_place | servo_arc::Arc<T>::drop_slow]

Status: RESOLVED FIXED

(Core :: DOM: Animation, defect, P1)

Description

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

Linux (and a very few Mac) crashes.
LOTS of crashes with 0xe5e5e5e5 in 70/71; appears to start in 69.
See https://crash-stats.mozilla.com/signature/?product=Firefox&signature=core%3A%3Aptr%3A%3Areal_drop_in_place%20%7C%20core%3A%3Aptr%3A%3Areal_drop_in_place%20%7C%20servo_arc%3A%3AArc%3CT%3E%3A%3Adrop_slow&date=%3E%3D2019-07-07T19%3A03%3A00.000Z&date=%3C2020-01-07T19%3A03%3A00.000Z

Perhaps related to bug 1581121?

This bug is for crash report bp-dccdc490-c828-4a69-9fa8-a4a320200107.

Top 10 frames of crashing thread:

0 libxul.so core::ptr::real_drop_in_place /usr/src/rustc-1.37.0/src/libcore/ptr/mod.rs:197
1 libxul.so core::ptr::real_drop_in_place /usr/src/rustc-1.37.0/src/libcore/ptr/mod.rs:197
2 libxul.so servo_arc::Arc<T>::drop_slow /build/firefox-ta7VRv/firefox-71.0+build5/servo/components/servo_arc/lib.rs:359
3 libxul.so Servo_AnimationValue_Release /build/firefox-ta7VRv/firefox-71.0+build5/servo/components/style/gecko/arc_types.rs:57
4 libxul.so ForEachNode<mozilla::layers::ForwardIterator, mozilla::layers::Layer*, > /build/firefox-ta7VRv/firefox-71.0+build5/gfx/layers/TreeTraversal.h:138
5 libxul.so ForEachNode<mozilla::layers::ForwardIterator, mozilla::layers::Layer*, > /build/firefox-ta7VRv/firefox-71.0+build5/gfx/layers/TreeTraversal.h:142
6 libxul.so ForEachNode<mozilla::layers::ForwardIterator, mozilla::layers::Layer*, > /build/firefox-ta7VRv/firefox-71.0+build5/gfx/layers/TreeTraversal.h:142
7 libxul.so TransformShadowTree /build/firefox-ta7VRv/firefox-71.0+build5/gfx/layers/composite/AsyncCompositionManager.cpp:1383
8 libxul.so CompositeToTarget /build/firefox-ta7VRv/firefox-71.0+build5/gfx/layers/ipc/CompositorBridgeParent.cpp:1008
9 libxul.so non-virtual thunk to mozilla::layers::CompositorBridgeParent::CompositeToTarget 

Comment 1

[Jeff Muizelaar [:jrmuizel]]

This needs servo_arc::Arc<T>::drop_slow added to the skip list

Comment 2

[Jeff Muizelaar [:jrmuizel]]

https://github.com/mozilla-services/socorro/pull/5172

Comment 3

[Sotaro Ikeda [:sotaro]]

Almost all crashes had Servo_AnimationValue_Release(). From it, RefPtr<RawServoAnimationValue> might be invalid.

:hiro, do you have an idea about the crash?

Comment 4

[Hiroyuki Ikezoe (:hiro)]

I think crashes on Linux (32bits) were caused by the same issue in bug 1581121.
Crashes on Mac look different it crashed on the main thread.

Comment 5

[Hiroyuki Ikezoe (:hiro)]

Hmm, but the call stack looks sane unlike bug 1581121.

Comment 6

[BugBot [:suhaib / :marco/ :calixte]]

The priority flag is not set for this bug.
:botond, could you have a look please?

For more information, please visit auto_nag documentation.

Comment 7

[Sotaro Ikeda [:sotaro]]

:hiro, can you cc me to bug 1581121? I want to compare this bug to it.

Comment 8

[Botond Ballo [:botond]]

This is coming from the OMTA code in AsyncCompositionManager. Not sure if we have a component for OMTA, but DOM: Animation seems close.

Comment 9

[Brian Birtles (:birtles)]

Sotaro, mind if I assign this to you for now? You can re-assign to Hiro or Boris if it looks particularly animation-specific.

Comment 10

[Hiroyuki Ikezoe (:hiro)]

I believe all crashes related to animation are ubuntu 32bits specific, it's bug 1581121. Crashes on MacOSX is not animation specific.

Comment 11

[Brian Birtles (:birtles)]

I'm afraid I can't see bug 1581121 but please dupe / re-purpose this bug as you see fit.

Comment 12

[Hiroyuki Ikezoe (:hiro)]

Assigning to myself, let's see whether bug 1581121 fixes this crash too.

Comment 13

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

Updated signature.
Still bad; and I suspect the gap is another signature change.

This (and bug 1581121) are causing a LOT of crashes (and they're both sec bugs)

Comment 14

[Hiroyuki Ikezoe (:hiro)]

It looks like basically the crash has stopped in Firefox 78.

My hypothesis is that Simon Giesecke's recent great changes on nsTArray fixed the crash reason in our code, or it gave compilers (rust/clang) enough information to avoid a kind of like optimizations to cause this crash.

That being said, I could still find two crashes on Firefox 78, either is not on Linux though, one is on Mac (bp-f2c1786c-e593-4d08-8aa5-8db4b0200705) and the other is on Window7 (bp-0279aee4-6d7c-445c-a79f-bb23b0200702). The Mac one looks bogus to me, but the latter, Window 7 one looks related to this, it crashes on the main-thread but it's also on x86.

Comment 15

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

In july this dropped a ton. Looking at the crashes, I see no crashes after 77 with these signatures. I'm going to call this fixed