Thread deadlock when using the media2 extension

[REQUIRED] Issue description

I am experiencing thread deadlocks on the project I am working on. It uses the new media2 extension and the latest Exoplayer library artifact versions (2.12.0). The issue occurs when a non-default Executor is being set as a callback executor to a MediaLibraryService.MediaLibrarySession.Builder. The created MediaLibrarySession is connected to a SessionPlayerConnector.

[REQUIRED] Reproduction steps

I’ve attached thread dumps at the end of the report which display what’s getting blocked and why. The issue reproduction depends on changes of the buffering state being reported to SessionPlayerConnector.setBufferingState().

At some point MediaSessionImpl… is calling SessionPlayerConnector.getBufferingState() which internally posts a callback to the main thread’s event loop, then blocks the thread waiting for the callback to execute (SessionPlayerConnector.runPlayerCallableBlocking()). The problem is this is all happening while an internal lock is being held inside MediaSessionImplBase.createPlaybackStateCompat(), which will not be released until the main thread looper processes the posted callbacks. At the same on the main thread event queue there’s a preceding callback which is trying to acquire the same lock, thus waiting forever.

To me it seems the preceding callback originates from a call to SessionPlayerConnector.notifySessionPlayerCallback() and has something to do with the following code and comments in SessionCallback’s constructor:

// Register PlayerCallback and make it to be called before the ListenableFuture set the result. // It help the PlayerCallback to update allowed commands before pended Player APIs are executed. sessionPlayerConnector.registerPlayerCallback(Runnable::run, new PlayerCallback());

At the time of the deadlock there were 2 registered SessionPlayer.PlayerCallback/Executor pairs, the one from the comment above, and the second being a MediaSessionImplBase.SessionPlayerCallback tied to the media session’s callback executor.

[REQUIRED] Link to test content

The issue isn’t media content-specific, but related to state handling and a concurrency issue.

[REQUIRED] A full bug report captured from the device

bugreport-sdk_gphone_x86_64-RSR1.200819.001.A1-2020-09-29-12-01-30.zip

Thread dump Thread dump

[REQUIRED] Version of ExoPlayer being used

2.12.0 (+ media2 extension)

[REQUIRED] Device(s) and version(s) of Android being used

This isn’t device or API-specific, reproduced and reported with an Android 11 (API30) emulator, (Image rev. 8, emulator v30.0.26) on a Windows 10 machine

[SungsooLim]

AndroidX media2 1.1.0 was release, and expect this issue is resolved in the next release of media2-extension.

[georgi-neykov-hub]

Thank you for the effort and support.

On Mon, Dec 14, 2020, 01:46 Sungsoo Lim [e-mail] wrote:

AndroidX media2 1.1.0 was release, and expect this issue is resolved in the next release of media2-extension.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/google/ExoPlayer/issues/8011#issuecomment-744090339, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABIFWVKZ3HQDIZMV2S4C743SUVG6FANCNFSM4R5QXEBQ .