Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Main thread in waiting state #81

Closed
oseparovic opened this issue Dec 6, 2017 · 3 comments
Closed

Main thread in waiting state #81

oseparovic opened this issue Dec 6, 2017 · 3 comments

Comments

@oseparovic
Copy link
Contributor

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
Copy link
Owner

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
Copy link
Contributor Author

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 added a commit that referenced this issue Jan 5, 2018
@protyposis
Merge branch 'feature/80-fix-deadlock' into develop
c65ee4c 
Fixes GitHub issue #81.
@protyposis
Copy link
Owner

Fixed in 4.3.3.

@kuoliangkwong kuoliangkwong mentioned this issue Feb 1, 2018
Closed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@protyposis @oseparovic