Crash in [@ _platform_memmove$VARIANT$Merom | nsTArray_Impl<T>::ReplaceElementsAtInternal<T> | mozilla::TrackBuffersManager::InsertFrames]
Categories
(Core :: Audio/Video: Playback, defect, P2)
Tracking
()
People
(Reporter: sg, Unassigned)
References
Details
(Keywords: crash, csectype-bounds, sec-high)
Crash Data
This bug is for crash report bp-6840c22d-88ad-4c85-abea-4be070200819.
Top 10 frames of crashing thread:
0 libsystem_platform.dylib _platform_memmove$VARIANT$Merom
1 XUL RefPtr<mozilla::MediaRawData>* nsTArray_Impl<RefPtr<mozilla::MediaRawData>, nsTArrayInfallibleAllocator>::ReplaceElementsAtInternal<nsTArrayInfallibleAllocator, RefPtr<mozilla::MediaRawData> > xpcom/ds/nsTArray.h:2327
2 XUL mozilla::TrackBuffersManager::InsertFrames dom/media/mediasource/TrackBuffersManager.cpp:2136
3 XUL mozilla::Box::ReadAsSlice dom/media/mp4/Box.cpp:192
4 XUL mozilla::media::Interval<mozilla::media::TimeUnit>* nsTArray_Impl<mozilla::media::Interval<mozilla::media::TimeUnit>, nsTArrayInfallibleAllocator>::AppendElementsInternal<nsTArrayInfallibleAllocator, mozilla::media::Interval<mozilla::media::TimeUnit>, nsTArrayInfallibleAllocator> xpcom/ds/nsTArray.h:2484
5 XUL mozilla::media::IntervalSet<mozilla::media::TimeUnit>::Add dom/media/Intervals.h:360
6 libmozglue.dylib moz_xrealloc memory/mozalloc/mozalloc.cpp:72
7 XUL nsTArrayInfallibleAllocator::ResultTypeProxy nsTArray_base<nsTArrayInfallibleAllocator, nsTArray_RelocateUsingMemutils>::EnsureCapacity<nsTArrayInfallibleAllocator> xpcom/ds/nsTArray-inl.h:210
8 XUL mozilla::TrackBuffersManager::ProcessFrames dom/media/mediasource/TrackBuffersManager.cpp:1995
9 XUL empty_buffer
Lot's of different signatures for this on OS X due to various variants of platform_memmove, multiplying with the change from ReplaceElementsAt to ReplaceElementsAtInternal. I am not 100% sure if I caught all of them.
|
Reporter | |
Updated•5 years ago
|
|
|
Reporter | |
Comment 1•5 years ago
|
||
There are also crashes with signature [@ mozilla::MediaRawData::Clone] being called from TrackBuffersManager::GetSample which look related.
Also Bug 1659941 might not be really an OOM, but trying to allocate a huge array due to the required capacity drawn from a corrupted memory location.
|
||
Updated•5 years ago
|
|
|
||
Updated•5 years ago
|
|
||
Comment 2•5 years ago
|
||
The severity field is not set for this bug.
:bryce, could you have a look please?
For more information, please visit auto_nag documentation.
The increase we see at the end of June looks driven by ESR 78. It's not clear why there's so many crashes on ESR 78.
It's not clear to me how actionable this is. I'm happy to delve deeper if there are suggestions what media can do.
|
||
Comment 4•5 years ago
•
|
||
As best I can tell, these crashes started appearing in larger quantities on 2020-07-07 on both the 77.0.1esr and 78.0.1esr branches at once:
I've been digging around for a patch (or small number of patches) that could explain this, but so far I haven't found it (them).
|
|
||
Comment 5•5 years ago
|
||
|
||
Comment 6•5 years ago
|
||
The spike in numbers appears related to moving OSX10.9 - 10.11 folks to ESR. ESR branches show unthrottled crash amounts. I thought only Windows crashes were sampled on Release, but if Mac crashes are also sampled on Release that would certainly explain the jump (there was none, it just looks worse). But if Mac crashes on Release are processed like ESR then something definitely happened in 78.x for users of old Mac OSs.
The crashes aren't only on Mac though. At a much lower rate it does look like there's some underlying bounds problem in media code. Here's a windows crash that looks potentially exploitable: bp-7608318f-8c0b-4892-b557-c178d0200818 Maybe there's a clue in the mini dump and what objects are getting processed at that point.
|
|
||
Comment 7•5 years ago
•
|
||
Thanks, Dan. That's the best (most plausible) explanation I've heard so far of the sudden increase in this bug's crashes in early July -- that from that point Mac ESR crashes stopped being throttled. So the increase is only an artifact of how Mozilla measures them, and didn't happen in real life.
|
|
||
Comment 8•5 years ago
•
|
||
(Following up comment #7)
Or possibly an artifact of the sudden increase of Mac users on ESR. Either way, though, the increase in crashes doesn't seem to have been caused by any contemporaneous change on the ESR branch.
|
|
Reporter | |
Updated•5 years ago
|
|
|
Reporter | |
Updated•5 years ago
|
|
||
Comment 9•5 years ago
|
||
(In reply to Bryce Seager van Dyk (:bryce) from comment #3)
The increase we see at the end of June looks driven by ESR 78. It's not clear why there's so many crashes on ESR 78.
It's not clear to me how actionable this is. I'm happy to delve deeper if there are suggestions what media can do.
Hey Bryce -- Like bug 1584956, this also looks stalled to me. I'm NI'ing you for a sanity-check that I'm not missing something. Thanks!
(In reply to Maire Reavy [:mreavy] from comment #9)
(In reply to Bryce Seager van Dyk (:bryce) from comment #3)
The increase we see at the end of June looks driven by ESR 78. It's not clear why there's so many crashes on ESR 78.
It's not clear to me how actionable this is. I'm happy to delve deeper if there are suggestions what media can do.
Hey Bryce -- Like bug 1584956, this also looks stalled to me. I'm NI'ing you for a sanity-check that I'm not missing something. Thanks!
I think that's a fair assessment. Until we figure out the root cause of bug 1665411 I don't think I can action this.
|
||
Updated•3 years ago
|
|
||
Updated•3 years ago
|
|
||
Comment 12•3 years ago
|
||
Since the bug is closed, the stalled keyword is now meaningless.
For more information, please visit auto_nag documentation.
|
|
||
Updated•2 years ago
|
Description
•