Closed
Bug 1497149
Opened 7 years ago
Closed 7 years ago
Crash in OOM | large | NS_ABORT_OOM | nsTArray_base<T>::EnsureCapacity<T> | mozilla::dom::HTMLMediaElement::DispatchAsyncEvent
Categories
(Core :: Audio/Video, defect, P2)
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
=============================================================
Comment 1•7 years ago
|
||
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)
Comment 2•7 years ago
|
||
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)
Comment 3•7 years ago
|
||
The pushlog for build 20181006100304:
https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=54cb6a2f028b&tochange=6f233fd06aac
Reporter | ||
Comment 4•7 years ago
|
||
Yeah, I filed it because it looked like a potential spike on new nightly versions.
Reporter | ||
Comment 5•7 years ago
|
||
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…
Reporter | ||
Updated•7 years ago
|
OS: Windows 10 → All
Comment 6•7 years ago
|
||
The only thing in this push touching the media code is bug 1495871. Looks unlikely to be the culprit too.
Flags: needinfo?(nfroyd)
Comment 7•7 years ago
|
||
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)
Assignee | ||
Comment 8•7 years ago
|
||
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)
Updated•7 years ago
|
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]
Assignee | ||
Comment 9•7 years ago
|
||
Updated•7 years ago
|
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
Assignee | ||
Comment 10•7 years ago
|
||
Comment 11•7 years ago
|
||
Pushed by jbruaroey@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/3ded0ccdc4a5
Avoid nulling mSeekDOMPromise on OOM, and use IgnoreErrors(). r=jya
Comment 12•7 years ago
|
||
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
Updated•7 years ago
|
Priority: -- → P2
Comment 13•7 years ago
|
||
bugherder |
https://hg.mozilla.org/mozilla-central/rev/3ded0ccdc4a5
https://hg.mozilla.org/mozilla-central/rev/b59cdee37257
Status: NEW → RESOLVED
Closed: 7 years ago
status-firefox64:
--- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla64
Updated•7 years ago
|
Assignee: nobody → jib
Updated•7 years ago
|
status-firefox62:
--- → unaffected
status-firefox63:
--- → unaffected
status-firefox-esr60:
--- → unaffected
You need to log in
before you can comment on or make changes to this bug.
Description
•