protyposis/MediaPlayer-Extended

Main thread in waiting state

oseparovic opened this issue · 3 comments

oseparovic commented

I see this ANR occasionally in my app analytics. Any ideas how to investigate this?

Affected devices:

  • Samsung Galaxy Note4 (trltetmo), 3072MB RAM, Android 6.0
  • Xiaomi Redmi Note 4 (mido), 3072MB RAM, Android 7.0
  • Motorola DROID Turbo 2 (kinzie), 3072MB RAM, Android 7.0
  • OnePlus 2 (OnePlus2), 4096MB RAM, Android 6.0
"main" tid=1 Waiting 
"main" prio=5 tid=1 Waiting
  | group="main" sCount=1 dsCount=0 obj=0x766d4388 self=0xb47a4500
  | sysTid=19265 nice=0 cgrp=apps sched=0/0 handle=0xb6f46b4c
  | state=S schedstat=( 19045326897 5899928824 29193 ) utm=1621 stm=283 core=1 HZ=100
  | stack=0xbe422000-0xbe424000 stackSize=8MB
  | held mutexes=
  at java.lang.Object.wait! (Native method)
- waiting on <0x05179217> (a java.lang.Object)
  at net.protyposis.android.mediaplayer.MediaPlayer.stop (MediaPlayer.java:671)
- locked <0x05179217> (a java.lang.Object)
  at net.protyposis.android.mediaplayer.MediaPlayer.release (MediaPlayer.java:707)
  at net.protyposis.android.mediaplayer.VideoView.release (VideoView.java:312)
  at net.protyposis.android.mediaplayer.VideoView.surfaceDestroyed (VideoView.java:422)
  at android.view.SurfaceView.updateWindow (SurfaceView.java:696)
  at android.view.SurfaceView.onWindowVisibilityChanged (SurfaceView.java:316)
  at android.view.View.dispatchWindowVisibilityChanged (View.java:10439)
  at android.view.ViewGroup.dispatchWindowVisibilityChanged (ViewGroup.java:1328)
  at android.view.ViewGroup.dispatchWindowVisibilityChanged (ViewGroup.java:1328)
  at android.view.ViewGroup.dispatchWindowVisibilityChanged (ViewGroup.java:1328)
  at android.view.ViewRootImpl.performTraversals (ViewRootImpl.java:1800)
  at android.view.ViewRootImpl.doTraversal (ViewRootImpl.java:1487)
  at android.view.ViewRootImpl$TraversalRunnable.run (ViewRootImpl.java:7450)
  at android.view.Choreographer$CallbackRecord.run (Choreographer.java:920)
  at android.view.Choreographer.doCallbacks (Choreographer.java:695)
  at android.view.Choreographer.doFrame (Choreographer.java:631)
  at android.view.Choreographer$FrameDisplayEventReceiver.run (Choreographer.java:906)
  at android.os.Handler.handleCallback (Handler.java:739)
  at android.os.Handler.dispatchMessage (Handler.java:95)
  at android.os.Looper.loop (Looper.java:158)
  at android.app.ActivityThread.main (ActivityThread.java:7225)
  at java.lang.reflect.Method.invoke! (Native method)
  at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run (ZygoteInit.java:1230)
  at com.android.internal.os.ZygoteInit.main (ZygoteInit.java:1120)
protyposis commented

Looking at the code, I think there's only one possibility this can happen. The stop() method calls mPlaybackThread.release(), and this release() returns instantly when the PlaybackThread is not alive any more, instead of calling mReleaseSyncLock.notify() as it normally would. Due to the missing notify(), mReleaseSyncLock.wait() within stop() is waiting forever.

This can be fixed by returning a boolean flag from stop() and conditionally calling mReleaseSyncLock.wait(). I'll schedule it for the next release.

oseparovic commented

Awesome work as always. I'll look through our crash logs and see if I can dig up any other useful error reports for you.

There's mention of a freeze that occurs for certain users when watching a video but it's not something I can reproduce on any of my devices. Hopefully this is it!

protyposis commented

Fixed in 4.3.3.