This seems to happen randomly during test startup, about 0.5% of the time. It succeeds on retry, which is why we haven't seen test suite failures on the FYI bot. I'm nervous about adding more mash_browser_tests to the main waterfall until we sort out this flake.
https://chromium-swarm.appspot.com/task?id=3b6661e0d27ae310&refresh=10&show_raw=1&wide_logs=true
[ RUN ] FileSystemApiTestForRequestFileSystem.Background
[17804:17858:0131/111245.974357:FATAL:service.cc(266)] Check failed: gfx::ClientNativePixmapFactory::GetInstance().
#0 0x000003e9513c base::debug::StackTrace::StackTrace()
#1 0x000003eaf34c logging::LogMessage::~LogMessage()
#2 0x000002d62c5c ui::Service::OnStart()
#3 0x0000048b9840 service_manager::ServiceContext::OnStart()
#4 0x00000526cc87 service_manager::mojom::ServiceStubDispatch::AcceptWithResponder()
#5 0x0000048ba106 service_manager::mojom::ServiceStub<>::AcceptWithResponder()
#6 0x0000052438fc mojo::InterfaceEndpointClient::HandleValidatedMessage()
#7 0x00000525aa46 mojo::FilterChain::Accept()
#8 0x000005244c95 mojo::InterfaceEndpointClient::HandleIncomingMessage()
#9 0x00000524d99d mojo::internal::MultiplexRouter::ProcessIncomingMessage()
#10 0x00000524cedc mojo::internal::MultiplexRouter::Accept()
#11 0x00000525aa46 mojo::FilterChain::Accept()
#12 0x0000052429e5 mojo::Connector::ReadSingleMessage()
#13 0x000005243301 mojo::Connector::ReadAllAvailableMessages()
#14 0x0000052431a9 mojo::Connector::OnHandleReadyInternal()
#15 0x000002519327 mojo::SimpleWatcher::DiscardReadyState()
#16 0x000005260ca6 mojo::SimpleWatcher::OnHandleReady()
#17 0x0000052611c1 _ZN4base8internal7InvokerINS0_9BindStateIMN4mojo13SimpleWatcherEFvijRKNS3_18HandleSignalsStateEEJNS_7WeakPtrIS4_EEijS5_EEEFvvEE7RunImplIRKS9_RKNSt3__15tupleIJSB_ijS5_EEEJLm0ELm1ELm2ELm3EEEEvOT_OT0_NSI_16integer_sequenceImJXspT1_EEEE
#18 0x000003e958f5 base::debug::TaskAnnotator::RunTask()
#19 0x000003f4d0b9 base::internal::IncomingTaskQueue::RunTask()
#20 0x000003eb6d0b base::MessageLoop::RunTask()
https://cs.chromium.org/chromium/src/services/ui/service.cc?type=cs&q=ui::Service::OnStart&sq=package:chromium&l=266
This CL changed factory initialization but it's 10 months old: https://codereview.chromium.org/2803523002
I'm guessing this is a side effect of putting the ash service and the ui service in the same process -- maybe both threads are trying to access the same g_instance of the factory?
Comment 1 by jamescook@chromium.org
, Jan 31 2018I can repro this locally with a linux-chromeos debug build if I make this code change: void ClientNativePixmapFactory::SetInstance( ClientNativePixmapFactory* instance) { DCHECK(!g_instance); DCHECK(instance); // **** LOG(ERROR) << "JAMES SetInstance " << instance; base::debug::StackTrace().Print(); // **** g_instance = instance; } This changes the timing enough to cause the failure. It looks like SetInstance() is being called by the ash service on one thread: #2 0x7f34d9c3015d gfx::ClientNativePixmapFactory::SetInstance() #3 0x7f34d16ab475 aura::Env::Init() #4 0x7f34d16ab311 aura::Env::CreateInstance() #5 0x7f34cb388a3a views::AuraInit::Init() #6 0x7f34cb3887a9 views::AuraInit::Create() #7 0x7f34cd1a5d48 ash::WindowManagerService::OnStart() But GetInstance() is checked by the ui service on a different thread, with the stack in the bug description.