New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.
Starred by 2 users

Issue metadata

Status: Verified
Owner:
Email to this user bounced
Closed: Nov 2011
Components:
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 2
Type: Bug

Blocked on:
issue 98975

Restricted
  • Only users with EditIssue permission may comment.



Sign in to add a comment
link

Issue 96861: [Layout Test] media/audio-repaint.html is flaky on WIN (TIMEOUT) due to composite filter crash

Reported by imasaki@chromium.org, Sep 16 2011 Project Member

Issue description

media/audio-repaint.html is flaky on WIN/Mac (IMAGE/TIMEOUT/TEXT)

http://test-results.appspot.com/dashboards/flakiness_dashboard.html#showExpectations=true&tests=media%2Faudio-repaint.html

For WIN (debug), I see the following exception.


e:\b\build\slave\Webkit_Win__dbg__2_\build\src\webkit\support\webkit_support.cc(78): error: Failed
[8128:6928:3174218:FATAL:composite_filter.cc(284)] Check failed: (status_cb_.is_null() && callback_.get()) || (!status_cb_.is_null() && !callback_.get()). 
Backtrace:
	base::debug::StackTrace::StackTrace [0x0089A3C1+33] (e:\b\build\slave\webkit_win__dbg__2_\build\src\base\debug\stack_trace_win.cc:149)
	logging::LogMessage::~LogMessage [0x00884CFF+63] (e:\b\build\slave\webkit_win__dbg__2_\build\src\base\logging.cc:561)
	media::CompositeFilter::DispatchPendingCallback [0x00E3858A+218] (e:\b\build\slave\webkit_win__dbg__2_\build\src\media\base\composite_filter.cc:286)
	media::CompositeFilter::OnCallSequenceDone [0x00E389DE+110] (e:\b\build\slave\webkit_win__dbg__2_\build\src\media\base\composite_filter.cc:401)
	media::CompositeFilter::SerialCallback [0x00E387E3+227] (e:\b\build\slave\webkit_win__dbg__2_\build\src\media\base\composite_filter.cc:352)
	DispatchToMethod<media::CompositeFilter,void (__thiscall media::CompositeFilter::*)(void)> [0x00E3C0AF+15] (e:\b\build\slave\webkit_win__dbg__2_\build\src\base\tuple.h:541)
	ScopedRunnableMethodFactory<media::CompositeFilter>::RunnableMethod<void (__thiscall media::CompositeFilter::*)(void),Tuple0>::Run [0x00E3B5A0+64] (e:\b\build\slave\webkit_win__dbg__2_\build\src\base\task.h:164)
	media::CompositeFilter::OnCallback [0x00E38B36+102] (e:\b\build\slave\webkit_win__dbg__2_\build\src\media\base\composite_filter.cc:431)
	DispatchToFunction<void (__cdecl*)(MessageLoop *,CancelableTask *),MessageLoop *,CancelableTask *> [0x00E3C0D6+22] (e:\b\build\slave\webkit_win__dbg__2_\build\src\base\tuple.h:619)
	RunnableFunction<void (__cdecl*)(MessageLoop *,CancelableTask *),Tuple2<MessageLoop *,CancelableTask *> >::Run [0x00E3B66A+42] (e:\b\build\slave\webkit_win__dbg__2_\build\src\base\task.h:477)
	media::TaskToCallbackAdapter::RunWithParams [0x00E2D875+53] (e:\b\build\slave\webkit_win__dbg__2_\build\src\media\base\callback.cc:22)
	CallbackRunner<Tuple0>::Run [0x00B4D600+48] (e:\b\build\slave\webkit_win__dbg__2_\build\src\base\callback_old.h:79)
	media::AudioRendererBase::Stop [0x00E28C86+118] (e:\b\build\slave\webkit_win__dbg__2_\build\src\media\filters\audio_renderer_base.cc:63)
	media::CompositeFilter::CallFilter [0x00E3836E+222] (e:\b\build\slave\webkit_win__dbg__2_\build\src\media\base\composite_filter.cc:269)
	media::CompositeFilter::SerialCallback [0x00E38853+339] (e:\b\build\slave\webkit_win__dbg__2_\build\src\media\base\composite_filter.cc:362)
	DispatchToMethod<media::CompositeFilter,void (__thiscall media::CompositeFilter::*)(void)> [0x00E3C0AF+15] (e:\b\build\slave\webkit_win__dbg__2_\build\src\base\tuple.h:541)
	ScopedRunnableMethodFactory<media::CompositeFilter>::RunnableMethod<void (__thiscall media::CompositeFilter::*)(void),Tuple0>::Run [0x00E3B5A0+64] (e:\b\build\slave\webkit_win__dbg__2_\build\src\base\task.h:164)
	base::subtle::TaskClosureAdapter::Run [0x022A6102+50] (e:\b\build\slave\webkit_win__dbg__2_\build\src\base\task.cc:56)
	base::internal::Invoker1<0,base::internal::InvokerStorage1<void (__thiscall base::subtle::TaskClosureAdapter::*)(void),base::subtle::TaskClosureAdapter *>,void (__thiscall base::subtle::TaskClosureAdapter::*)(void)>::DoInvoke [0x022A064D+45] (e:\b\build\slave\webkit_win__dbg__2_\build\src\base\bind_internal.h:595)
	base::Callback<void __cdecl(void)>::Run [0x008B91EF+47] (e:\b\build\slave\webkit_win__dbg__2_\build\src\base\callback.h:269)
	MessageLoop::RunTask [0x02296CB5+293] (e:\b\build\slave\webkit_win__dbg__2_\build\src\base\message_loop.cc:478)
	MessageLoop::DeferOrRunPendingTask [0x02296DF3+51] (e:\b\build\slave\webkit_win__dbg__2_\build\src\base\message_loop.cc:495)
	MessageLoop::DoWork [0x022977CD+221] (e:\b\build\slave\webkit_win__dbg__2_\build\src\base\message_loop.cc:682)
	base::MessagePumpDefault::Run [0x02302023+195] (e:\b\build\slave\webkit_win__dbg__2_\build\src\base\message_pump_default.cc:23)
	MessageLoop::RunInternal [0x02296A07+247] (e:\b\build\slave\webkit_win__dbg__2_\build\src\base\message_loop.cc:443)
	MessageLoop::RunHandler [0x022967DE+46] (e:\b\build\slave\webkit_win__dbg__2_\build\src\base\message_loop.cc:417)
	MessageLoop::Run [0x022960EA+58] (e:\b\build\slave\webkit_win__dbg__2_\build\src\base\message_loop.cc:341)
	base::Thread::Run [0x022ADC56+22] (e:\b\build\slave\webkit_win__dbg__2_\build\src\base\threading\thread.cc:129)
	base::Thread::ThreadMain [0x022ADDC1+225] (e:\b\build\slave\webkit_win__dbg__2_\build\src\base\threading\thread.cc:163)
	base::`anonymous namespace'::ThreadFunc [0x008B8230+96] (e:\b\build\slave\webkit_win__dbg__2_\build\src\base\threading\platform_thread_win.cc:42)
	GetModuleFileNameA [0x7C80B729+442]

For Mac 10.6, I see the actual background images are different from time to time.
 

Comment 1 by scherkus@chromium.org, Sep 21 2011

Labels: Mstone-16 Stability-CodeYellow
Owner: acolwell@chromium.org
Status: Assigned
composite filter DCHECK!

Comment 2 Deleted

Comment 3 by imasaki@chromium.org, Sep 22 2011

Summary: [Layout Test] media/audio-repaint.html is flaky on WIN (TIMEOUT) due to composite filter crash

Comment 5 by acolwell@chromium.org, Oct 6 2011

Blockedon: 98975

Comment 6 by fischman@google.com, Oct 7 2011

Manually bugdroiding:

The following revision refers to this bug:
    http://src.chromium.org/viewvc/chrome?view=rev&revision=104540

------------------------------------------------------------------------
r104540 | fischman@chromium.org (:amifischman0) | Fri Oct 07 12:12:21 PDT 2011

Changed paths:
 M http://src.chromium.org/viewvc/chrome/trunk/src/media/base/composite_filter.cc?r1=104540&r2=104539&pathrev=104540
 M http://src.chromium.org/viewvc/chrome/trunk/src/media/filters/ffmpeg_video_decoder.cc?r1=104540&r2=104539&pathrev=104540
 M http://src.chromium.org/viewvc/chrome/trunk/src/content/renderer/media/audio_renderer_impl.cc?r1=104540&r2=104539&pathrev=104540
 M http://src.chromium.org/viewvc/chrome/trunk/src/media/filters/ffmpeg_demuxer.cc?r1=104540&r2=104539&pathrev=104540
 M http://src.chromium.org/viewvc/chrome/trunk/src/media/filters/video_renderer_base.cc?r1=104540&r2=104539&pathrev=104540

Fix hangs & crashes in teardown-during-Seek.

Hangs:
- AudioRendererImpl: Don't hold lock_ in the call to Join() b/c OnStop wants to
  acquire the lock before exiting.
- FFmpegDemuxerStream::Stop: signal EOS to waiting read callbacks (instead of
  silently dropping them on the floor) so decoders can exit instead of stalling
  (and causing renderers to stall).

Crashes:
- CompositeFilter::Stop: clear out the Seek callback when Stopping.
- FFmpegVideoDecoder::ProduceVideoFrame: early-return if already stopped (racing
  with webkit repaints makes this necessary).

Also fixed a bunch of mis-indentation where I saw it.

BUG= 98975 , 98948 , 98955 , 96861 
TEST=trybots, manual


Review URL: http://codereview.chromium.org/8184003
------------------------------------------------------------------------

Comment 7 by fischman@google.com, Oct 7 2011

The above (r104540) should fix this test.
Aaron: you want to remove the test_expectation next week after confirming no more crashes on the flakiness dashboard after the CL went in?  (note this bug is just for WIN, which as of right now is showing a 5% failure rate, most recently on Oct 4).

Comment 8 by bugdroid1@chromium.org, Oct 17 2011

Project Member
Labels: merge-merged-874
The following revision refers to this bug:
    http://src.chromium.org/viewvc/chrome?view=rev&revision=105930

------------------------------------------------------------------------
r105930 | fischman@chromium.org | Mon Oct 17 14:47:52 PDT 2011

Changed paths:
 M http://src.chromium.org/viewvc/chrome/branches/874/src/media/base/composite_filter.cc?r1=105930&r2=105929&pathrev=105930
 M http://src.chromium.org/viewvc/chrome/branches/874/src/media/filters/ffmpeg_video_decoder.cc?r1=105930&r2=105929&pathrev=105930
 M http://src.chromium.org/viewvc/chrome/branches/874/src/content/renderer/media/audio_renderer_impl.cc?r1=105930&r2=105929&pathrev=105930
 M http://src.chromium.org/viewvc/chrome/branches/874/src/media/filters/ffmpeg_demuxer.cc?r1=105930&r2=105929&pathrev=105930
 M http://src.chromium.org/viewvc/chrome/branches/874/src/media/filters/video_renderer_base.cc?r1=105930&r2=105929&pathrev=105930

Merge 104540 - Fix hangs & crashes in teardown-during-Seek.

Hangs:
- AudioRendererImpl: Don't hold lock_ in the call to Join() b/c OnStop wants to
acquire the lock before exiting.
- FFmpegDemuxerStream::Stop: signal EOS to waiting read callbacks (instead of
silently dropping them on the floor) so decoders can exit instead of stalling
(and causing renderers to stall).

Crashes:
- CompositeFilter::Stop: clear out the Seek callback when Stopping.
- FFmpegVideoDecoder::ProduceVideoFrame: early-return if already stopped (racing
with webkit repaints makes this necessary).

Also fixed a bunch of mis-indentation where I saw it.

BUG= 98975 ,  98948 ,  98955 ,  96861 
TEST=trybots, manual
Review URL: http://codereview.chromium.org/8294027
------------------------------------------------------------------------

Comment 9 by fischman@chromium.org, Oct 17 2011

Owner: imasaki@chromium.org
Kenji: I believe my CL cured all the TIMEOUTs (and crashes causing them), leaving behind only the need to rebaseline for some image diffs (edges of the rendered 0's are different on some platforms; I suspect skia/CG moves).  Do you want to rebaseline/resolve this bug?

Comment 10 by imasaki@chromium.org, Oct 17 2011

Sure. Thanks for taking care of this.

Comment 11 by laforge@google.com, Oct 24 2011

Labels: -Mstone-16 MovedFrom-16 Mstone-17

Comment 12 by fischman@google.com, Oct 24 2011

Kenji: ping?  Can you rebaseline the test & resolve this bug per my comment #9?

Comment 13 by imasaki@chromium.org, Oct 31 2011

Status: Started

Comment 15 by imasaki@google.com, Nov 1 2011

http://trac.webkit.org/changeset/98981 is committed for GPU rebaseline.

Comment 16 by imasaki@chromium.org, Nov 1 2011

Status: Fixed
http://trac.webkit.org/changeset/98996 is landed for test expectation change. Resolving.

Comment 17 by imasaki@chromium.org, Nov 23 2011

Status: Verified

Comment 18 by bugdroid1@chromium.org, Oct 13 2012

Project Member
Blockedon: -chromium:98975 chromium:98975
Labels: Restrict-AddIssueComment-Commit
This issue has been closed for some time. No one will pay attention to new comments.
If you are seeing this bug or have new data, please click New Issue to start a new bug.

Comment 19 by bugdroid1@chromium.org, Mar 10 2013

Project Member
Labels: -Area-WebKit -WebKit-LayoutTests -Feature-Media -Mstone-17 Cr-Content Cr-Internals-Media M-17 Cr-Content-LayoutTests

Comment 20 by bugdroid1@chromium.org, Mar 13 2013

Project Member
Labels: -Restrict-AddIssueComment-Commit Restrict-AddIssueComment-EditIssue

Comment 21 by bugdroid1@chromium.org, Apr 6 2013

Project Member
Labels: -Cr-Content Cr-Blink

Comment 22 by bugdroid1@chromium.org, Apr 6 2013

Project Member
Labels: -Cr-Content-LayoutTests Cr-Blink-LayoutTests

Comment 23 by sshru...@google.com, May 18 2016

Labels: Test-Layout

Sign in to add a comment