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

Issue 684126 link

Starred by 1 user
Status: WontFix
Owner:
█ staraz@chromium.org
Last visit > 30 days ago
Closed: Jan 2017
Cc:
█ junov@chromium.org
█ xlai@chromium.org
█ fsam...@chromium.org
Components:
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 1
Type: Bug-Regression



Sign in to add a comment

FATAL:surface_manager.cc(395): Check failed: valid_frame_sink_ids_.count(frame_sink_id) == 1u (0 vs. 1)

Project Member Reported by kbr@chromium.org, Jan 23 2017 
Intermittent assertion failures running OffscreenCanvas pixel tests:
https://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_rel_ng/builds/376204

Pixel_OffscreenCanvasAccelerated2D (gpu_tests.pixel_integration_test.PixelIntegrationTest) ... [22693:22693:0123/122103.137306:FATAL:surface_manager.cc(395)] Check failed: valid_frame_sink_ids_.count(frame_sink_id) == 1u (0 vs. 1)
#0 0x7f943244fafe base::debug::StackTrace::StackTrace()
#1 0x7f9432468e9b logging::LogMessage::~LogMessage()
#2 0x7f94333bea03 cc::SurfaceManager::UnregisterSurfaceFactoryClient()
#3 0x7f94333a916f cc::CompositorFrameSinkSupport::~CompositorFrameSinkSupport()
#4 0x7f94319b8119 content::OffscreenCanvasCompositorFrameSink::~OffscreenCanvasCompositorFrameSink()
#5 0x7f94319b8fd0 std::_Hashtable<>::erase()
#6 0x7f943252639b mojo::InterfaceEndpointClient::NotifyError()
#7 0x7f943252c37a mojo::internal::MultiplexRouter::ProcessNotifyErrorTask()
#8 0x7f943252a5c1 mojo::internal::MultiplexRouter::ProcessTasks()
#9 0x7f9432529271 mojo::internal::MultiplexRouter::OnPipeConnectionError()
#10 0x7f943252280d mojo::Connector::HandleError()
#11 0x7f9432522e71 mojo::Connector::OnHandleReadyInternal()
#12 0x7f94325346fa mojo::Watcher::OnHandleReady()
#13 0x7f9430b3db34 _ZN4base8internal13FunctorTraitsIMN5media29GpuVideoDecodeAcceleratorHostEFvjEvE6InvokeIRKNS_7WeakPtrIS3_EEJRKNS2_22VideoDecodeAccelerator5ErrorEEEEvS5_OT_DpOT0_
#14 0x7f94324fc8de base::debug::TaskAnnotator::RunTask()
#15 0x7f94324701ad base::MessageLoop::RunTask()
#16 0x7f9432470866 base::MessageLoop::DoWork()
#17 0x7f94324726e9 base::MessagePumpGlib::Run()
#18 0x7f943246ff05 base::MessageLoop::RunHandler()
#19 0x7f9432496eec base::RunLoop::Run()
#20 0x7f943230e69a ChromeBrowserMainParts::MainMessageLoopRun()
#21 0x7f94316d9399 content::BrowserMainLoop::RunMainMessageLoopParts()
#22 0x7f94316dcb77 content::BrowserMainRunnerImpl::Run()
#23 0x7f94316d44de content::BrowserMain()
#24 0x7f9432014237 content::RunNamedProcessTypeMain()
#25 0x7f9432014c86 content::ContentMainRunnerImpl::Run()
#26 0x7f94320136d0 content::ContentMain()
#27 0x7f9430840141 ChromeMain
#28 0x7f94292d6f45 __libc_start_main
#29 0x7f943083ffd1 <unknown>


Olivia, could you please take this? It's been seen on the CQ so is high priority.

I couldn't easily find a good bug that this one should block, but please do in order to indicate that recent work probably regressed this. Thanks.

Comment 1 by xlai@chromium.org, Jan 24 2017

Cc: fsam...@chromium.org xlai@chromium.org
Owner: staraz@chromium.org
I checked the build where this test is failing and found that it came from staraz@'s CL
https://codereview.chromium.org/2612083002/#ps250001 which is not landed yet. The
failed build (tryserver linux 376204) came from Patch Set 13. 

When I look at the
code at Patch Set 13, it was quite obvious to me that the addition of "support_.InvalidateFrameSinkId();" in the destructor of OffscreenCanvasCompositorFrameSink results in the frame sink id being erased from valid_frame_sink_ids_ before SurfaceManager::UnregisterSurfaceFactoryClient() is invoked, and that's why the assert failure. In the latest patch, this part
is fixed and then the linux bot is green.

kbr@: Did you see a failed test on CQ instead of tryserver? Currently, by doing static analysis on the latest Chromium code,
I think the order of erasing framesinkid from valid_frame_sink_ids_ is correct,

Comment 2 by staraz@chromium.org, Jan 25 2017

Status: Fixed (was: Assigned)
xlai@: yes I realized the problem and patchset 15 removed the InvalidateFrameSinkId(). Could you confirm that the failure is gone?

And why would an unlanded CL cause CQ to crash?

Comment 3 by xlai@chromium.org, Jan 25 2017

Status: WontFix (was: Fixed)
Marking it as won't fixed because this is from a CL that's not landed yet.

kbr@: Please feel free to reopen this issue, if actually this is a failure on CQ and not just in tryserver.

Comment 4 by kbr@chromium.org, Jan 30 2017 

Ah. Sorry, I should have realized that this was a CL that hadn't landed yet, rather than a random flake.
►

Sign in to add a comment