Issue metadata
Sign in to add a comment
|
WebRtcGetUserMediaBrowserTest.VideoInIFrameAndCloseInSuccessCb flaky on win7_chromium_rel_ng |
||||||||||||||||||||||
Issue descriptionWebRtcGetUserMediaBrowserTest.VideoInIFrameAndCloseInSuccessCb is flaky on the tryserver win7_chromium_rel_ng, causing content_browsertests to fail and valid CQ jobs to be retried. There may be up to 15 instances of this failure in the last 200 builds: https://luci-milo.appspot.com/buildbot/tryserver.chromium.win/win7_chromium_rel_ng/?limit=200 A few examples: https://luci-milo.appspot.com/buildbot/tryserver.chromium.win/win7_chromium_rel_ng/8202 https://luci-milo.appspot.com/buildbot/tryserver.chromium.win/win7_chromium_rel_ng/8197 https://luci-milo.appspot.com/buildbot/tryserver.chromium.win/win7_chromium_rel_ng/8171 https://luci-milo.appspot.com/buildbot/tryserver.chromium.win/win7_chromium_rel_ng/8169 https://luci-milo.appspot.com/buildbot/tryserver.chromium.win/win7_chromium_rel_ng/8168 I see Issue 727601 was filed about the related tests: WebRtcGetUserMedia{OldConstraints,}BrowserTest::AudioInIFrameAndCloseInSuccessCb but that bug was filed in May and there's been no action on it except to disable tests. This is affecting the CQ so I'm marking it P1. Here's the log excerpt of one of the failures. Note that per: https://luci-logdog.appspot.com/v/?s=chromium%2Fbb%2Ftryserver.chromium.win%2Fwin7_chromium_rel_ng%2F8202%2F%2B%2Frecipes%2Fsteps%2Fcontent_browsertests__with_patch_%2F0%2Flogs%2FWebRtcGetUserMediaBrowserTest.VideoInIFrameAndCloseInSuccessCb%2F0 once this test fails, the 3 implicit retries all fail. [4996:688:0930/114505.810:19437568:FATAL:media_stream_video_source.cc(257)] Check failed: STARTING == state_ (1 vs. 6) Backtrace: base::debug::StackTrace::StackTrace [0x0239A1B7+55] base::debug::StackTrace::StackTrace [0x023B479A+10] content::MediaStreamVideoSource::OnStartDone [0x039E0FB6+277] content::MediaStreamVideoCapturerSource::OnRunStateChanged [0x03A03BC1+369] base::internal::Invoker<base::internal::BindState<void (__thiscall content::MediaStreamVideoCapturerSource::*)(media::VideoCaptureParams const &,bool),base::internal::UnretainedWrapper<content::MediaStreamVideoCapturerSource>,media::VideoCaptureParams>,vo [0x03A03F1F+31] content::MediaStreamVideoCapturerSource::OnRunStateChanged [0x03A03C86+566] ??$DispatchToMethodImpl@PAVPPB_ImageData_Proxy@proxy@ppapi@@P8123@AEXHHABUPP_Size@@W4PP_Bool@@PAVHostResource@3@PAUPP_ImageDataDesc@@PAVSharedMemoryHandle@base@@@ZV?$tuple@HHUPP_Size@@W4PP_Bool@@@std@@V?$tuple@VHostResource@ppapi@@UPP_ImageDataDesc@@VShar [0x022CF954+169] content::MediaStreamVideoCapturerSource::RestartSourceImpl [0x03A03EED+381] base::RepeatingCallback<void __cdecl(bool)>::Run [0x010FB716+24] base::internal::FunctorTraits<base::RepeatingCallback<void __cdecl(enum blink::mojom::WebBluetoothResult)>,void>::Invoke<base::RepeatingCallback<void __cdecl(enum blink::mojom::WebBluetoothResult)>,enum blink::mojom::WebBluetoothResult> [0x016196B2+91] base::internal::Invoker<base::internal::BindState<base::RepeatingCallback<void __cdecl(enum blink::mojom::WebBluetoothResult)>,enum blink::mojom::WebBluetoothResult>,void __cdecl(void)>::RunOnce [0x0161B6F3+19] base::debug::TaskAnnotator::RunTask [0x023AFDD2+258] blink::scheduler::TaskQueueManager::ProcessTaskFromWorkQueue [0x0207A076+943] blink::scheduler::TaskQueueManager::DoWork [0x020790A3+675] base::internal::FunctorTraits<void (__thiscall content::WebMediaPlayerMS::*)(bool),void>::Invoke<base::WeakPtr<content::WebMediaPlayerMS>,bool> [0x01251800+26] base::internal::InvokeHelper<1,void>::MakeItSo<void (__thiscall content::WebMediaPlayerMS::*)(bool),base::WeakPtr<content::WebMediaPlayerMS>,bool> [0x01251881+34] base::internal::Invoker<base::internal::BindState<void (__thiscall content::WebMediaPlayerMS::*)(bool),base::WeakPtr<content::WebMediaPlayerMS>,bool>,void __cdecl(void)>::RunOnce [0x039B40E7+23] base::debug::TaskAnnotator::RunTask [0x023AFDD2+258] base::internal::IncomingTaskQueue::RunTask [0x023C418B+107] base::MessageLoop::RunTask [0x0234F1E6+614] base::MessageLoop::DeferOrRunPendingTask [0x0234DE8E+238] base::MessageLoop::DoWork [0x0234E714+756] base::MessagePumpDefault::Run [0x023C47EB+27] base::MessageLoop::Run [0x0234EF77+103] base::RunLoop::Run [0x02344FD5+117] content::RendererMain [0x0393804B+507] content::RunNamedProcessTypeMain [0x015062DE+203] content::ContentMainRunnerImpl::Run [0x015061E6+294] service_manager::Main [0x02F4CE4F+538] content::ContentMain [0x01505931+39] content::LaunchTests [0x0212C4E1+552] main [0x03B1645A+55] __scrt_common_main_seh [0x03AC822A+248] (f:\dd\vctools\crt\vcstartup\src\startup\exe_common.inl:283) BaseThreadInitThunk [0x74B6337A+18] RtlInitializeExceptionChain [0x76F692B2+99] RtlInitializeExceptionChain [0x76F69285+54]
,
Sep 30 2017
,
Oct 2 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/528f235373c555c850c6e26c6b321e3c948a321a commit 528f235373c555c850c6e26c6b321e3c948a321a Author: Guido Urdaneta <guidou@chromium.org> Date: Mon Oct 02 08:41:11 2017 Handle stopped sources in MediaStreamVideoSource callbacks. A source may be stopped during processing of Start(), StopForRestart() or Restart due to the frame being destroyed. Handle that case, instead of DCHECKing that the state is always the expected one in the normal case. Bug: 770494 Change-Id: Ib8dc0f3bb377257ad8f49aa98814ee7a61d9607e Reviewed-on: https://chromium-review.googlesource.com/692937 Reviewed-by: Henrik Boström <hbos@chromium.org> Commit-Queue: Guido Urdaneta <guidou@chromium.org> Cr-Commit-Position: refs/heads/master@{#505560} [modify] https://crrev.com/528f235373c555c850c6e26c6b321e3c948a321a/content/renderer/media/media_stream_video_source.cc
,
Oct 2 2017
|
|||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||
Comment 1 by guidou@chromium.org
, Sep 30 2017Status: Assigned (was: Untriaged)