1264849 - crash in OOM | large | mozalloc_abort | mozalloc_handle_oom | moz_xrealloc | nsTArray_base<T>::EnsureCapacity<T> | nsTArray_Impl<T>::AppendElement<T> | nsAnimationManager::QueueEvent

Status: RESOLVED DUPLICATE of bug 1264396

(Core :: CSS Parsing and Computation, defect)

Description

[Nicholas Nethercote [inactive]]

This bug was filed from the Socorro interface and is 
report bp-e07ac6e2-2341-476d-9e07-16bd82160414.
=============================================================

There have been 15 crashes with this signature in Nightly since this first appeared in Nightly 20160412030235. The one linked above OOM'd on an allocation request of 183 MB! And I've seen others almost as high: 162 MB, 60 MB, etc.

The obvious thing to say is that this allocation should be fallible. But an even better question: why is the nsAnimationManager event queue getting so large?

Comment 1

[Nicholas Nethercote [inactive]]

I see another 11 OOMs with this very similar signature.

Comment 2

[Nicholas Nethercote [inactive]]

birtles, can you please take a look?

Comment 3

[Brian Birtles (:birtles)]

Looking

Comment 4

[Brian Birtles (:birtles)]

This is likely a dupe of bug 1264396 for which a fix has already landed on m-i.

I suspect we're getting one of those pages that attempts to animate display which sends us into an infinite loop creating and destroying animations. And, I suppose as part of that we end up queuing animationstart events. I further suppose we don't actually dispatch any of the events before we go around and do another loop hence the queue of events just keeps growing and growing--and the block of memory we need to allocate likewise just keeps growing.

I think the best thing for now is just to see if this resolves over the weekend when bug 1264396 arrives in nightlies.

If this is bug 1264396 then using fallible allocation or some data structure that doesn't require allocating a contiguous block of memory (like a linked list) wouldn't really help--they'd just be delaying the inevitable.

Bug 1134163 (in progress) will help somewhat since it will mean we won't queue animation events while building animations but, again, it won't fix bug 1264396.

Comment 5

[Nicholas Nethercote [inactive]]

(In reply to Brian Birtles (:birtles) from comment #4)
> This is likely a dupe of bug 1264396 for which a fix has already landed on
> m-i.

Sounds plausible! Thank you for the quick response.

Comment 6

[Brian Birtles (:birtles)]

I've added a note to check the crash stats on Monday.

Comment 7

[Brian Birtles (:birtles)]

I'm not seeing any crashes with this signature since Nightly 2016041403. That seems consistent with the theory that bug 1264396 fixes it since that landed in m-c and seems to have been in the Nightly for 2016-04-15 (according to https://gijsk.github.io/diditland/).

I'm inclined to close this as RESOLVED FIXED bug 1264396 but perhaps we should wait another day or two to be sure.

Comment 8

[Brian Birtles (:birtles)]

Still no more crashes since bug 1264396 landed. I think this is fixed.