IllegalStateException when releasing DefaultDrmSession

[fpitters]

We are seeing a weird crash (on Firebase Crashlytics) after bumping to 2.14.2 (from 2.13.2) with the following stacktrace:

Fatal Exception: java.lang.IllegalStateException
       at com.google.android.exoplayer2.util.Assertions.checkState(Assertions.java:84)
       at com.google.android.exoplayer2.drm.DefaultDrmSession.release(DefaultDrmSession.java:308)
       at com.google.android.exoplayer2.drm.DefaultDrmSessionManager$PreacquiredSessionReference.lambda$release$1(DefaultDrmSessionManager.java:1015)
       at com.google.android.exoplayer2.drm.DefaultDrmSessionManager$PreacquiredSessionReference.lambda$release$1$DefaultDrmSessionManager$PreacquiredSessionReference(DefaultDrmSessionManager.java:3)
       at com.google.android.exoplayer2.drm.-$$Lambda$DefaultDrmSessionManager$PreacquiredSessionReference$nYc-XCZkgUmlTVMJKF9VQKrj-NU.run(-.java:3)
       at android.os.Handler.handleCallback(Handler.java:761)
       at android.os.Handler.dispatchMessage(Handler.java:98)
       at android.os.Looper.loop(Looper.java:156)
       at android.os.HandlerThread.run(HandlerThread.java:61)

We haven't been able to reproduce it locally.

The incidence is low, few ~5 out of 25K a day and not device specific, happening across all brands. Although Huawei devices have 40% of the share.

We use Dash with Widevine encryption.

I thought this issue was related: #9193 but it might be is not.

We'll update the status in the upcoming weeks once we move to 2.15.0.

Thanks

[icbaker]

The stack trace provided indicates that a PreacquiredSessionReference is trying to release an underlying DefaultDrmSession that's already fully released (referenceCount == 0).

I've spent some time studying the code in DefaultDrmSessionManager and I haven't come up with a sequence of operations that would allow this to happen. Every PreacquiredSessionReference instance 'holds' a single reference count of its underlying DefaultDrmSession and nobody should be releasing that reference except the PreacquiredSessionReference (and it contains logic to ensure it only releases it at most once). Of course there might be a bug somewhere, but without being able to reproduce it (which is understandable because it sounds like a rare race condition) it's hard to do anything except comb through the code by hand.

I wonder if you could provide some extra info about how your app configures DRM playback that might help guide me towards an answer:

• Are you using MediaItem's DRM fields or passing MediaSource instances directly to the player?
• Are you directly instantiating DefaultDrmSessionManager and/or providing a custom DrmSessionManagerProvider to MediaSourceFactory?
• If you're directly instantiating DefaultDrmSessionManager do you ever directly call prepare() or release() on it? (separately to any calls from ExoPlayer library code).
• Do you customise or disable the DefaultDrmSessionManager.Builder#setSessionKeepaliveTimeoutMs() property?

[google-oss-bot]

Hey @fpitters. We need more information to resolve this issue but there hasn't been an update in 14 weekdays. I'm marking the issue as stale and if there are no new updates in the next 7 days I will close it automatically.

If you have more information that will help us get to the bottom of this, just add a comment!

[Luisemtza]

Hello, we have the same problem. We are using version 2.15 and we cannot replicate the problem, we can only see it through Firebase Crashlytics

com.google.android.exoplayer2.util.Assertions.checkState (Assertions.java:84)
com.google.android.exoplayer2.drm.DefaultDrmSession.release (DefaultDrmSession.java:314)
com.google.android.exoplayer2.drm.DefaultDrmSessionManager$PreacquiredSessionReference.lambda$release$1 (DefaultDrmSessionManager.java:1017)
com.google.android.exoplayer2.drm.DefaultDrmSessionManager$PreacquiredSessionReference.lambda$release$1$DefaultDrmSessionManager$PreacquiredSessionReference (DefaultDrmSessionManager.java)
com.google.android.exoplayer2.drm.-$$Lambda$DefaultDrmSessionManager$PreacquiredSessionReference$nYc-XCZkgUmlTVMJKF9VQKrj-NU.run (-.java:2)
android.os.Handler.handleCallback (Handler.java:938)
android.os.Handler.dispatchMessage (Handler.java:99)
android.os.Looper.loop (Looper.java:250)
android.os.HandlerThread.run (HandlerThread.java:67)

Are you using MediaItem's DRM fields or passing MediaSource instances directly to the player?

We are using MediaSource

Are you directly instantiating DefaultDrmSessionManager and/or providing a custom DrmSessionManagerProvider to MediaSourceFactory?

We are directly instantiating DefaultDrmSessionManager

If you're directly instantiating DefaultDrmSessionManager do you ever directly call prepare() or release() on it? (separately to any calls from ExoPlayer library code).

No, We don't call directly this methods.

Do you customise or disable the DefaultDrmSessionManager.Builder#setSessionKeepaliveTimeoutMs() property?

No, We don't are setting any value.

I hope it can help with the solution.

[icbaker]

@Luisemtza Are you able to post the code snippet you use to instantiate your DefaultDrmSessionManager?

Do you instantiate a new DefaultDrmSessionManager for every MediaSource or re-use them? If you re-use them, do you ever re-use them across multiple Player instances?

[Luisemtza]

Hi @icbaker, of corse:

private DefaultDrmSessionManager getDefaultDrmSessionManager(
    DefaultHttpDataSourceFactory dataSourceFactory,
    ConfigPlayer configPlayer,
    String phonogramId) {
  DefaultDrmSessionManager.Builder builder = new DefaultDrmSessionManager.Builder();
  if (configPlayer != null && configPlayer.forceUseLV3()) {
    builder.setUuidAndExoMediaDrmProvider(
        C.WIDEVINE_UUID,
        uuid -> {
          try {
	    FrameworkMediaDrm mediaDrm = FrameworkMediaDrm.newInstance(uuid);
	    mediaDrm.setPropertyString(WidevineUtils.SECURITY_LEVEL, WidevineUtils.LEVEL_3);
	    return mediaDrm;
	} catch (UnsupportedDrmException e) {
	  return null;
        }
      });
  }
  return builder.build(new DrmCallback(dataSourceFactory, configPlayer, phonogramId, true));
}

DrmCallBack is our imlpementation of MediaDrmCallback.

We are instantiate a new DefaultDrmSessionManager each MediaSource.

Regards

[icbaker]

Thanks! That all looks pretty normal, nothing suspicious jumps out that would relate to the exception in this issue (which suggests there is a bug somewhere in DefaultDrmSessionManager, we just can't find it).

---

Aside: This is not correct - you shouldn't be returning null from ExoMediaDrm.Provider#acquireExoMediaDrm. If this line ever executes it will almost immediately generate an NPE inside DefaultDrmSessionManager:

} catch (UnsupportedDrmException e) {
  return null;
}

You should return a DummyExoMediaDrm like FrameworkMediaDrm#DEFAULT_PROVIDER does (in fact you could rewrite your implementation to just wrap a call to FrameworkMediaDrm#DEFAULT_PROVIDER to avoid having to handle this exception yourself).

[google-oss-bot]

Hey @fpitters. We need more information to resolve this issue but there hasn't been an update in 14 weekdays. I'm marking the issue as stale and if there are no new updates in the next 7 days I will close it automatically.

If you have more information that will help us get to the bottom of this, just add a comment!

[icbaker]

The change linked above stops throwing an exception in this case (logs an error instead). I'm going to close this issue, even though this isn't quite as satisfactory as finding & fixing the actual underlying bug.