8000 Thread deadlock when using the media2 extension · Issue #8011 · google/ExoPlayer · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content
Thread deadlock when using the media2 extension #8011
Closed
@georgi-neykov-hub

Description

@georgi-neykov-hub

[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 5F71 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

Metadata

Metadata

Assignees

Labels

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions

    0