We are cancelling this event during reset, but the event may have already been dispatched at the time, blocking on the mutex. While it's blocking, reset() cancels the event, we're then unblocked and bad things(tm) happen.

related-to-bug: 2451174

1 files changed, 12 insertions, 0 deletions

diff --git a/media/libstagefright/AwesomePlayer.cpp b/media/libstagefright/AwesomePlayer.cpp
index 1c9f4fd..59a5f9d 100644
--- a/media/libstagefright/AwesomePlayer.cpp
+++ b/media/libstagefright/AwesomePlayer.cpp
@@ -401,6 +401,9 @@ void AwesomePlayer::notifyListener_l(int msg, int ext1, int ext2) {
 
 void AwesomePlayer::onBufferingUpdate() {
     Mutex::Autolock autoLock(mLock);
+    if (!mBufferingEventPending) {
+        return;
+    }
     mBufferingEventPending = false;
 
     if (mDurationUs >= 0) {
@@ -425,6 +428,9 @@ void AwesomePlayer::onStreamDone() {
     // Posted whenever any stream finishes playing.
 
     Mutex::Autolock autoLock(mLock);
+    if (!mStreamDoneEventPending) {
+        return;
+    }
     mStreamDoneEventPending = false;
 
     if (mFlags & LOOPING) {
@@ -918,6 +924,12 @@ void AwesomePlayer::postCheckAudioStatusEvent_l() {
 
 void AwesomePlayer::onCheckAudioStatus() {
     Mutex::Autolock autoLock(mLock);
+    if (!mAudioStatusEventPending) {
+        // Event was dispatched and while we were blocking on the mutex,
+        // has already been cancelled.
+        return;
+    }
+
     mAudioStatusEventPending = false;
 
     if (mWatchForAudioSeekComplete && !mAudioPlayer->isSeeking()) {