Closed Bug 1497149 Opened 11 months ago Closed 11 months ago

Crash in OOM | large | NS_ABORT_OOM | nsTArray_base<T>::EnsureCapacity<T> | mozilla::dom::HTMLMediaElement::DispatchAsyncEvent

Categories

(Core :: Audio/Video, defect, P2, critical)

Unspecified
All
defect

Tracking

()

RESOLVED FIXED
mozilla64
Tracking Status
firefox-esr60 --- unaffected
firefox62 --- unaffected
firefox63 --- unaffected
firefox64 --- fixed

People

(Reporter: gsvelto, Assigned: jib)

References

Details

(Keywords: crash, regression)

Crash Data

Attachments

(2 files)

This bug was filed from the Socorro interface and is
report bp-cba09fcf-5436-4aee-952e-5d2ec0181008.
=============================================================

Top 10 frames of crashing thread:

0 xul.dll NS_ABORT_OOM xpcom/base/nsDebugImpl.cpp:628
1 xul.dll nsTArray_base<nsTArrayInfallibleAllocator, nsTArray_CopyWithMemutils>::EnsureCapacity<nsTArrayInfallibleAllocator> xpcom/ds/nsTArray-inl.h
2 xul.dll mozilla::dom::HTMLMediaElement::DispatchAsyncEvent dom/html/HTMLMediaElement.cpp:6478
3 xul.dll void mozilla::dom::HTMLMediaElement::ChangeReadyState dom/html/HTMLMediaElement.cpp:6199
4 xul.dll mozilla::dom::HTMLMediaElement::UpdateReadyStateInternal dom/html/HTMLMediaElement.cpp:6046
5 xul.dll void mozilla::MediaDecoder::OnNextFrameStatus dom/media/MediaDecoder.cpp:449
6 xul.dll nsresult mozilla::detail::RunnableMethodImpl<RefPtr<mozilla::AudioTrackEncoder>, void  xpcom/threads/nsThreadUtils.h:1242
7 xul.dll mozilla::AutoTaskDispatcher::TaskGroupRunnable::Run xpcom/threads/TaskDispatcher.h:214
8 xul.dll mozilla::EventTargetWrapper::Runner::Run xpcom/threads/AbstractThread.cpp:150
9 xul.dll mozilla::SchedulerGroup::Runnable::Run xpcom/threads/SchedulerGroup.cpp:337

=============================================================
If we have an OOM there, it's likely because of an issue somewhere else.
That array will never contain more than 4-5 items at a time...

I would classify this unique crash as an odd one, unlikely to ever reproduce (cosmic rays, bit flips etc)
Actually, a few, all with build id >= 20181006100304

So this started with bug 1495904 , don't see how it could cause that however.
We attempt to set the message queue size > 2GiB (2,208,301,056 bytes)
Flags: needinfo?(jib)
Yeah, I filed it because it looked like a potential spike on new nightly versions.
I seem to have found another signature.
Crash Signature: [@ OOM | large | NS_ABORT_OOM | nsTArray_base<T>::EnsureCapacity<T> | mozilla::dom::HTMLMediaElement::DispatchAsyncEvent] → [@ OOM | large | NS_ABORT_OOM | nsTArray_base<T>::EnsureCapacity<T> | mozilla::dom::HTMLMediaElement::DispatchAsyncEvent] [@ OOM | large | mozalloc_abort | mozalloc_handle_oom | moz_xrealloc | nsTArray_base<T>::EnsureCapacity<T> | mozilla::dom::HTMLMedia…
OS: Windows 10 → All
The only thing in this push touching the media code is bug 1495871. Looks unlikely to be the culprit too.
Flags: needinfo?(nfroyd)
This is definitely related to a change in the seeking code as modified in bug 1495904 

In one of the dump, the array of events contains 138018815 elements.

And the events in there are:
do { seeking, timeupdate, waiting, timeupdate, seeking, canplay, playing, canplaythrough } while(true)
Blocks: 1495904
Flags: needinfo?(nfroyd)
Keywords: regression
The only thing I see wrong in the new code in bug 1495904 is that it forgets to check aRV in the case where creating a promise fails:

https://searchfox.org/mozilla-central/rev/29aea2a2a3bd0f5e25ce0b60a76053fb25ba5149/dom/html/HTMLMediaElement.cpp#2893

I could see this affect the symptom of an already present OOM situation.

We could try moving the creation of the promise back to where it was earlier, and check aRV like we used to.
Flags: needinfo?(jib)
Crash Signature: mozilla::dom::HTMLMediaElement::DispatchAsyncEvent] → mozilla::dom::HTMLMediaElement::DispatchAsyncEvent] [@ OOM | large | mozalloc_abort | mozalloc_handle_oom | moz_xrealloc | nsTArray_base<T>::EnsureCapacity<T> | nsTArray_Impl<T>::AppendElement<T> | mozilla::dom::HTMLMediaElement::DispatchAsyncEvent]
Attachment #9015322 - Attachment description: Bug 1497149 - Avoid nulling mSeekDOMPromise on OOM, and use IgnoredErrorResult. r?jya → Bug 1497149 - Avoid nulling mSeekDOMPromise on OOM, and use IgnoreErrors(). r?jya
Pushed by jbruaroey@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/3ded0ccdc4a5
Avoid nulling mSeekDOMPromise on OOM, and use IgnoreErrors(). r=jya
Pushed by jbruaroey@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/b59cdee37257
Don't refcount runnables unnecessarily in Async[Resolve|Reject]SeekDOMPromiseIfExists. r=jya
Priority: -- → P2
https://hg.mozilla.org/mozilla-central/rev/3ded0ccdc4a5
https://hg.mozilla.org/mozilla-central/rev/b59cdee37257
Status: NEW → RESOLVED
Closed: 11 months ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla64
Assignee: nobody → jib
You need to log in before you can comment on or make changes to this bug.