Closed Bug 1264849 Opened 6 years ago Closed 6 years ago

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

Categories

(Core :: CSS Parsing and Computation, defect)

x86
Windows NT
defect
Not set
critical

Tracking

()

RESOLVED DUPLICATE of bug 1264396
Tracking Status
firefox48 --- affected

People

(Reporter: n.nethercote, Unassigned)

Details

(Keywords: crash)

Crash Data

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?
I see another 11 OOMs with this very similar signature.
Crash Signature: [@ OOM | large | mozalloc_abort | mozalloc_handle_oom | moz_xrealloc | nsTArray_base<T>::EnsureCapacity<T> | nsTArray_Impl<T>::AppendElement<T> | nsAnimationManager::QueueEvent] → [@ OOM | large | mozalloc_abort | mozalloc_handle_oom | moz_xrealloc | nsTArray_base<T>::EnsureCapacity<T> | nsTArray_Impl<T>::AppendElement<T> | nsAnimationManager::QueueEvent] [@ OOM | large | mozalloc_abort | mozalloc_handle_oom | moz_xrealloc | nsTAr…
birtles, can you please take a look?
Flags: needinfo?(bbirtles)
Looking
Component: Layout → CSS Parsing and Computation
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.
Flags: needinfo?(bbirtles)
(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.
I've added a note to check the crash stats on Monday.
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.
Still no more crashes since bug 1264396 landed. I think this is fixed.
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 1264396
You need to log in before you can comment on or make changes to this bug.