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

RESOLVED FIXED in Firefox 55

Status

()

--
critical
RESOLVED FIXED
a year ago
a year ago

People

(Reporter: ziggi, Assigned: gerald)

Tracking

({crash})

54 Branch
mozilla55
x86_64
Windows 10
crash
Points:
---

Firefox Tracking Flags

(firefox-esr52 wontfix, firefox53 wontfix, firefox54 wontfix, firefox55 fixed)

Details

(crash signature)

Attachments

(1 attachment)

(Reporter)

Description

a year ago
This bug was filed from the Socorro interface and is 
report bp-2ee8a067-688d-46a6-b404-dac180170513.
=============================================================
(Reporter)

Comment 1

a year ago
Constant crashes somehow linked to certain video elements on a webpage.

Updated

a year ago
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)
(Assignee)

Comment 4

a year ago
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 https://hg.mozilla.org/releases/mozilla-aurora/annotate/105e456d811b/mfbt/Vector.h#l680 , 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 hidden (mozreview-request)

Comment 6

a year ago
mozreview-review
Comment on attachment 8875091 [details]
Bug 1364828 - Use nsTArray (with fallible append) in mp4_demuxer::ByteWriter -

https://reviewboard.mozilla.org/r/146462/#review150640

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+

Comment 7

a year ago
Pushed by gsquelart@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/4795dae51ea6
Use nsTArray (with fallible append) in mp4_demuxer::ByteWriter - r=jya

Comment 8

a year ago
bugherder
https://hg.mozilla.org/mozilla-central/rev/4795dae51ea6
Status: UNCONFIRMED → RESOLVED
Last Resolved: a year ago
status-firefox55: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla55
status-firefox53: --- → unaffected
status-firefox54: --- → unaffected
status-firefox-esr52: --- → unaffected
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.
status-firefox53: unaffected → wontfix
status-firefox54: unaffected → wontfix
status-firefox-esr52: unaffected → affected
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 :)
status-firefox-esr52: affected → wontfix
You need to log in before you can comment on or make changes to this bug.