diff options
author | qinmin@chromium.org <qinmin@chromium.org@0039d316-1c4b-4281-b951-d872f2087c98> | 2013-09-05 20:44:01 +0000 |
---|---|---|
committer | qinmin@chromium.org <qinmin@chromium.org@0039d316-1c4b-4281-b951-d872f2087c98> | 2013-09-05 20:44:01 +0000 |
commit | 76042fb7d2f19b68d728b737b11f2bcd9bab3b6d (patch) | |
tree | 27544ce5bc0f3e10ec37e1ac315b67d03d406645 /media | |
parent | 5764dccec76d49ca9a39d6472449004f8750b092 (diff) | |
download | chromium_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.cc | 1 |
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(); } |