Crash in Assertions.checkArgument on Samsung Devices with Android 7.0

[jschamburger]

Issue description

Hi,
since updating the ExoPlayer from 2.4.4 to 2.8.1, we noticed a significant amount of crashes on Samsung Devices with Android 7.0. Unfortunately, we haven't been able to reproduce the crash ourselves - we are aware of the issue only due to Crashlytics reports.
Therefore, this bug report certainly lacks some information, but maybe you might have an idea (or somebody might have encountered a similar problem) anyway. Even some explanation of possible reasons for this crash might help a lot.

Reproduction steps

From the logs, we know that the crash occurs after stopping a stream (using SimpleExoPlayer.stop()). The Player State becomes idle: onPlayerStateChanged, playWhenReady=true playbackState=1 and the DRM session is released. It seems to happen only for DRM protected streams and it does not happen every time a stream is stopped.

It might be worth noting that we are using a single ExoPlayer instance in several fragments within a ViewPager - users can switch streams by navigating within the ViewPager. However, the crash occurs not only when swiping left/right, but also when the user is stopping the stream in another way (e.g. by sending the app to the background).

Link to test content

I will email the link to dev.exoplayer@gmail.com using a subject in the format "Issue #1234".

Version of ExoPlayer being used

2.8.1 - we will update to 2.8.2 soon, but from the release notes, I don't think that this will fix our problem.

Device(s) and version(s) of Android being used

Android 7.0
only Samsung devices - most frequent devices:

• Galaxy Tab A 10.1 (42%)
• SM-J530F (7%)
• SM-J730F (6%)
• Galaxy J7 (2016) (4%)

A full bug report captured from the device

As mentioned above, I am unable to create a full bug report. This is the stack trace of the Crashlytics Crashes:
Fatal Exception: java.lang.IllegalArgumentException at com.google.android.exoplayer2.util.Assertions.checkArgument(SourceFile:39) at com.google.android.exoplayer2.upstream.DefaultAllocator.release(SourceFile:121) at com.google.android.exoplayer2.source.SampleQueue.clearAllocationNodes(SourceFile:609) at com.google.android.exoplayer2.source.SampleQueue.reset(SourceFile:111) at com.google.android.exoplayer2.source.SampleQueue.reset(SourceFile:98) at com.google.android.exoplayer2.source.chunk.ChunkSampleStream.onLoaderReleased(SourceFile:324) at com.google.android.exoplayer2.upstream.Loader$ReleaseTask.run(SourceFile:434) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1133) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:607) at java.lang.Thread.run(Thread.java:762)

I'm sorry for the sparse information here - hopefully you can support me anyway.

[ojw28]

That looks strange. It's also strange that we've not seen this reported by anyone else, unless it's somehow also specific to your application. Do you have any custom components that you're injecting into ExoPlayer, or are you using only components provided by the library?

[jschamburger]

Thanks for the quick answer! The fact that you haven't heard this from anyone else certainly points towards an issue in our application.

We are using a custom DrmSessionManager. In our application, rapid zapping between different streams (most of them DRM protected with the same init data) is crucial. Therefore, we have implemented a DrmSessionManager which uses a DefaultDrmSessionManager as delegate. When a DRM session with a specific UUID is aquired for the first time, our DrmSessionManager acquires an additional DRM session (using the respective method in DefaultDrmSessionManager). Additionally, we have a method to release all of these artificial DRM sessions which is called in our Activity's onPause(). Hence, the stream switching is a lot faster since the key request is made only for the start of the first stream because the artificial DRM session is kept open throughout the lifecycle of the app.
I'm aware that this is somewhat experimental, but with most devices (except the ones mentioned above), everything works fine.

Apart from that, we recently also implemented the dummy surface workaround discussed in #3835 (comment). However, we saw the crashes before implementing this workaround, so the issue should not be related to those changes.

[ojw28]

Do you have any customizations to the allocator? Are you using the standard DashMediaSource without doing anything special to it, or do you have customizations in the source as well. If so, they would be the most likely culprit.

Could you also check whether the reports you're getting are from official Samsung builds (vs some random ROM that a few users have flashed onto their devices)? Some build fingerprints would probably be helpful. Are the crashes just from these four devices?

[jschamburger]

We have no customizations to the allocator and we are using the standard DashMediaSource:
new DashMediaSource(uri, buildDataSourceFactory(false), new DashManifestParser(), new DefaultDashChunkSource.Factory(mediaDataSourceFactory), DEFAULT_MIN_LOADABLE_RETRY_COUNT, LIVE_PRESENTATION_DELAY_MS, mainHandler, eventLogger);

The crash occurs only on Samsung devices with Android 7.0, but the ones I mentioned above are only the most frequent devices:

Galaxy Tab A 10.1 43%
SM-J530F 8%
SM-J730F 6%
Galaxy J7(2016) 3%
SM-A320FL 1%
SM-J701F 1%
SM-G570F 1%
Everything else seems to be below 1%.

I am quite sure that the crashes are from official builds because

• according to Fabric, 0% of the devices are rooted (in my experience, most custom ROM users keep root access after flashing the custom ROM)
• Android 7.0 is the latest official version for the devices I checked
  Of course, this isn't conclusive proof, but I would assume that the devices use official Samsung builds.

Anyway, I will try to get some build fingerprints - this might be helpful for other issues as well. However, it will take some time until the next app version is released to the general public, so I will most likely get build fingerprint information in about 4 weeks.

[ojw28]

What do the percentages mean? Percentage of what? Thanks!

[jschamburger]

Sorry, should have mentioned that.

The percentages refer to the total number of crashes we had. We had ~500 crashes (~300 users) in the last 30 days, of which 100% were on Samsung devices with Android 7.0. Of those 500 crashes, 43% happened on the Galaxy Tab A etc.

[ojw28]

Can you derive an (approximate) percentage of playbacks that result in the crash on the affected devices? In particular, do you think this crash occurs for every playback on the affected devices, or sporadically?

You say you've been unable to reproduce the crash yourselves. Is this because you don't have one of the affected devices, or is it the case that you do have one of the affected devices, and are still unable to reproduce? If the latter, have you tried to reproduce with your proper release apk (e.g. install from Play Store, as your end users would), rather than just with a debug apk?

[jschamburger]

Unfortunately, I cannot derive a percentage of playbacks that result in the crash, but in the logs, I saw that not every playback leads to a crash on the affected devices. For some users, I have seen several "zapping" events (= playback stop + playback start of another stream) before the crash occurred.

I haven't been able to reproduce the crash because I do not have an affected device. I'm trying to get a Galaxy Tab A 10.1, but buying it (or using a "real device testing" service) needs approval, of course...
Judging by the numbers, I'm optimistic that I will be able to reproduce the crash on the device.
Good point regarding the release APK! I usually try the APK from the store first before installing the debug version in order to dig deeper.

[OMArikan]

I know that exception since 1.5.8 version. In old ExoPlayer i changed ASSERTIONS_ENABLED to false to get rid of crash but now I'm using 2.8.2 and same problem still appeared on Samsung Devices with OS 7.0. ASSERTIONS_ENABLED is public static final in ExoPlayerLibraryInfo and can't modified this time cause I'm using 2.8.2 with gradle implementation.

Device model ratio is changing according to popularity for application. For us 9 different Samsung devices with OS 7.0 facing with this exception. I couldn't reproduce crash yet but in a week around 90 crashes happened even %10 of total play session is using 2.8.2 on our app. I'm worried about that our app with real time play session over 20K how it will be affected.

By the way on my experience it's not related with neither media is protected with DRM or not nor content type is HLS or Dash. On my Crashlytics reports I set some keys about my contents and all possible combinations are available(Dash and HLS with or not DRM).

Here is my rendererFactory, allocator, loadControl and playerInstance;

DefaultRenderersFactory rendererFactory = new DefaultRenderersFactory(this, DefaultRenderersFactory.EXTENSION_RENDERER_MODE_OFF);
            DefaultAllocator allocator = new DefaultAllocator(true, C.DEFAULT_BUFFER_SEGMENT_SIZE);
            DefaultLoadControl loadControl = new DefaultLoadControl.Builder()
                    .setAllocator(allocator)
                    .setBufferDurationsMs(360000, 600000, 2500, 500)
                    .setTargetBufferBytes(C.LENGTH_UNSET)
                    .setPrioritizeTimeOverSizeThresholds(true)
                    .createDefaultLoadControl();

            player = ExoPlayerFactory.newSimpleInstance(rendererFactory, trackSelector, loadControl, drmSessionManager);

If you need any information by me let me know.

[jschamburger]

@OMArikan Thanks for your input! It's good to know that the problem occurs for others as well.

[ojw28]

@OMArikan Please can you provide some sample stack traces, so we can double check it's exactly the same issue.

[OMArikan]

@ojw28 I sent 3 sample stack traces files from crashlytics to dev.exoplayer@gmail.com with subject "Issue #4532". Also lately sent screen shot from Dashboard of Crashlytics to see only Samsung and OS 7.0

[ojw28]

Thanks. If either of you manage to reproduce the issue locally, it would be very useful to know if it reproduces only with your release build (but not with your dev build), and whether enabling/disabling ProGuard makes a difference. I suspect this might be a strange VM/ProGuard issue, but that's just a guess.

[OMArikan]

I tried many times to reproduce issue locally with same devices but never catch. I don't believe it'd be related with my app ProGuard if it's not related with 3rd party SDKs such as Retrofit, okHttp, Fabric, Adjust.