Make OOM failures in extractors non-fatal

[PaulWoitaschek]

In crashlytics I see some OOM where a really large amount of ram was tried to be allocated.

http://crashes.to/s/b7e79fa945f

That's about 304 MB the player tries to allocate while reading ID3 Data. Maybe the parsing went wrong?

It's ExoPlayer 2.4.0

[ojw28]

According to the link only a single user is affected. It's likely they have a single piece of broken content that they're trying to play repeatedly. We should be able to avoid OOM'ing in this case, but I don't think we can avoid playback failure.

It's not really possible to say without access to the problematic file. Is it possible for you to source it from your user?

[PaulWoitaschek]

I can't get the file. I use exoplayer to analyze the duration
https://github.com/PaulWoitaschek/MaterialAudiobookPlayer/blob/master/audiobook/src/main/java/de/ph1b/audiobook/misc/DurationAnalyzer.kt

So it's crashing each time he is opening the app.

[PaulWoitaschek]

Also I see other OOM where exoplayer tries to allocate > 30 MB in com.google.android.exoplayer2.extractor.mp4.AtomParsers.parseStbl (AtomParsers.java:362)

I'm not sure if that is wanted. Since I switched to ExoPlayer about 5% of my users receive crashes due to OOM errors.

[andrewlewis]

Please provide a link to the content that causes the MP4 parsing error.

[PaulWoitaschek]

I don't have access to the content of my users.

The stracktrace for these OOMs is always like this:

Fatal Exception: java.lang.OutOfMemoryError: Failed to allocate a 31891368 byte allocation with 10482944 free bytes and 9MB until OOM
       at com.google.android.exoplayer2.extractor.mp4.AtomParsers.parseStbl(AtomParsers.java:362)
       at com.google.android.exoplayer2.extractor.mp4.Mp4Extractor.processMoovAtom(Mp4Extractor.java:341)
       at com.google.android.exoplayer2.extractor.mp4.Mp4Extractor.processAtomEnded(Mp4Extractor.java:276)
       at com.google.android.exoplayer2.extractor.mp4.Mp4Extractor.readAtomPayload(Mp4Extractor.java:267)
       at com.google.android.exoplayer2.extractor.mp4.Mp4Extractor.read(Mp4Extractor.java:147)
       at com.google.android.exoplayer2.source.ExtractorMediaPeriod$ExtractingLoadable.load(ExtractorMediaPeriod.java:652)
       at com.google.android.exoplayer2.upstream.Loader$LoadTask.run(Loader.java:295)
       at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1113)
       at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:588)
       at java.lang.Thread.run(Thread.java:818)

So if I understand correctly you are allocation a really huge array here

[ojw28]

Yes, but only if the content actually indicates that we need to. For the first OOM reported here we could add some validation to fail the playback/extraction more gracefully. For the second one I'm not sure.

We should probably be making the OOM failure non-fatal; but I doubt we're going to get to the stage of actually playing this kind of content successfully; the content is likely malformed.

[PaulWoitaschek]

I'm really happy when the player does not crash on malformed files but just refuses to play them. My player is quite unstable right now.

[PaulWoitaschek]

Thanks a lot for the fast solution!