Closed Bug 1364828 Opened 6 years ago Closed 6 years ago

Crash in moz_abort | arena_run_split | arena_malloc_large | je_realloc | mozilla::Vector<T>::growStorageBy


(Core :: Audio/Video: Playback, defect)

54 Branch
Windows 10
Not set



Tracking Status
firefox-esr52 --- wontfix
firefox53 --- wontfix
firefox54 --- wontfix
firefox55 --- fixed


(Reporter: ziggi, Assigned: mozbugz)


(Keywords: crash)

Crash Data


(1 file)

This bug was filed from the Socorro interface and is 
report bp-2ee8a067-688d-46a6-b404-dac180170513.
Constant crashes somehow linked to certain video elements on a webpage.
Severity: major → critical
Component: General → Audio/Video
Keywords: crash
Product: Firefox → Core
Component: Audio/Video → Audio/Video: Playback
Jean-Yves - is this an OOM by another name?
Flags: needinfo?(jyavenard)
That code is supposed to be fallible.. :gerald made it so...

The stack trace is a bit confusing, looks like it has inline the writer code.

:gerald what do you think?
Flags: needinfo?(jyavenard) → needinfo?(gsquelart)
Hmm, I'm not 100% sure now...

I assumed Vector::append was fallible because of the `MOST_MUST_USE bool` return value.

But looking at , it says "Potentially fallible append operations" -- Does that mean that these operations can potentially fail when we ask for too much, or they can potentially fail depending on what type of objects are stored??

And trying to follow the code for Vector<uint8_t>, it seems to go to pod_alloc instead of maybe_pod_alloc, so we may in fact be doomed!

But I need more time to investigate...
Assignee: nobody → gsquelart
Flags: needinfo?(gsquelart)
Comment on attachment 8875091 [details]
Bug 1364828 - Use nsTArray (with fallible append) in mp4_demuxer::ByteWriter -

nsTArray has a great memory footprint than Vector :(
it allocates memory by a multiple of 2... and IIRC 8kB minimum
Attachment #8875091 - Flags: review?(jyavenard) → review+
Pushed by
Use nsTArray (with fallible append) in mp4_demuxer::ByteWriter - r=jya
Closed: 6 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla55
Both 53, 54 and esr52 are affected as the code was there too... May not show in the crash report but it's definitely there.

Bug 1307945 was supposed to make things infallible, but wasn't quite so.
There's a couple ESR52 reports in crash-stats, but doesn't seem high-volume enough to warrant backport consideration. Feel free to set the status back to affected and nominate it for approval if you feel otherwise, however :)
You need to log in before you can comment on or make changes to this bug.