summaryrefslogtreecommitdiffstats
path: root/media
diff options
context:
space:
mode:
authorqinmin@chromium.org <qinmin@chromium.org@0039d316-1c4b-4281-b951-d872f2087c98>2013-09-05 20:44:01 +0000
committerqinmin@chromium.org <qinmin@chromium.org@0039d316-1c4b-4281-b951-d872f2087c98>2013-09-05 20:44:01 +0000
commit76042fb7d2f19b68d728b737b11f2bcd9bab3b6d (patch)
tree27544ce5bc0f3e10ec37e1ac315b67d03d406645 /media
parent5764dccec76d49ca9a39d6472449004f8750b092 (diff)
downloadchromium_src-76042fb7d2f19b68d728b737b11f2bcd9bab3b6d.zip
chromium_src-76042fb7d2f19b68d728b737b11f2bcd9bab3b6d.tar.gz
chromium_src-76042fb7d2f19b68d728b737b11f2bcd9bab3b6d.tar.bz2
Cancel the starvation callback when MediaSourcePlayer::Release() gets called.
If we don't cancel the starvation callback, ProcessPendingEvents will get executed later when the callback fires. Because we use a BarrierClosure in ProcessPendingEvents() and the count is 0 as both audio and video decoders are released, OnPrefetchDone() will be immediately called. And this will cause ProcessPendingEvents() to get called again and again, thus crashing chrome. An alternative to this fix is to check count before creating the barrier. Logically starvation callback should not get called after Release(). BUG=285573 Review URL: https://chromiumcodereview.appspot.com/23672025 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@221509 0039d316-1c4b-4281-b951-d872f2087c98
Diffstat (limited to 'media')
-rw-r--r--media/base/android/media_source_player.cc1
1 files changed, 1 insertions, 0 deletions
diff --git a/media/base/android/media_source_player.cc b/media/base/android/media_source_player.cc
index d657fca..b2b4148 100644
--- a/media/base/android/media_source_player.cc
+++ b/media/base/android/media_source_player.cc
@@ -178,6 +178,7 @@ void MediaSourcePlayer::Release() {
reconfig_video_decoder_ = false;
playing_ = false;
pending_event_ = NO_EVENT_PENDING;
+ decoder_starvation_callback_.Cancel();
surface_ = gfx::ScopedJavaSurface();
ReleaseMediaResourcesFromManager();
}