Looks like the ClientNativePixmapFactory hasn't been set yet, causing a nullptr access at [1]. On the browser side, it is supposed to be installed fairly early one [2]. So either we are installing a null factory for some reason, or not installing a factory at all. Both seems pretty weird.

--> rjkroege@ for triage. Is it possible for ui::CreateClientNativePixmapFactoryOzone() to return null?

[1] https://cs.chromium.org/chromium/src/gpu/ipc/client/gpu_memory_buffer_impl_ozone_native_pixmap.cc?type=cs&sq=package:chromium&l=72
[2] https://cs.chromium.org/chromium/src/content/browser/browser_main_loop.cc?type=cs&sq=package:chromium&l=818

Changes to ClientNativePixmapFactory landed this morning in https://codereview.chromium.org/2705333006. I wonder if it's the problem?

The build of chrome I think is ~1wk old? (see original post)

I also looked at that CL at first, but I couldn't find any change in there that would affect the behaviour.

I can consistently repro this crash with ToT chrome r458750 on cave (not pixel).

* stop ui
* Edit /etc/chrome_dev.conf to add --mash
* start ui

Stack is a little mangled, two failures are mixed:
Received signal 11 SEGV_MAPERR 000000000000
#0 0x5d506c49401d base::debug::StackTrace::StackTrace()
#1 0x5d506c494460 base::debug::(anonymous namespace)::StackDumpSignalHandler()
#2 0x75963fc16530 <unknown>
#3 0x5d506a72d26a gpu::GpuMemoryBufferImplOzoneNativePixmap::CreateFromHandle()
#4 0x5d506a72c778 gpu::GpuMemoryBufferImpl::CreateFromHandle()
#5 0x5d506a850c1f [15635:15635:0322/151911.146073:ERROR:layer_tree_host_impl.cc(2248)] Forcing zero-copy tile initialization as worker context is missing
Received signal 11 SEGV_MAPERR 000000000000
#0 0x60d39c77801d ui::ClientGpuMemoryBufferManager::CreateGpuMemoryBuffer()
#6 0x5d506d4bd730 base::debug::StackTrace::StackTrace()cc::ResourceProvider::ScopedWriteLockGpuMemoryBuffer::GetGpuMemoryBuffer()

##17  0x0x60d39c7784605d506d4b7e0e  base::debug::(anonymous namespace)::StackDumpSignalHandler()
#2 0x76bd0cae6530 <unknown>
#3 0x60d39aa1126a cc::(anonymous namespace)::RasterBufferImpl::Playback()
#8 0x5d506d4e55bc cc::(anonymous namespace)::RasterTaskImpl::RunOnWorkerThread()
#9 0x5d506d43cdf0 gpu::GpuMemoryBufferImplOzoneNativePixmap::CreateFromHandle()
#4 0x60d39aa10778 gpu::GpuMemoryBufferImpl::CreateFromHandle()
#5 0x60d39ab34c1f cc::SingleThreadTaskGraphRunner::RunTaskWithLockAcquired()
#10 0x5d506d43cff0 ui::ClientGpuMemoryBufferManager::CreateGpuMemoryBuffer()
#6 0x60d39d7a1730 cc::ResourceProvider::ScopedWriteLockGpuMemoryBuffer::GetGpuMemoryBuffer()
#7 0x60d39d79be0e cc::SingleThreadTaskGraphRunner::Run()
#11 0x5d506c5018d5 cc::(anonymous namespace)::RasterBufferImpl::Playback()
#8 0x60d39d7c95bc cc::(anonymous namespace)::RasterTaskImpl::RunOnWorkerThread()
#9 0x60d39d720df0 [1:5:0322/151911.236040:ERROR:layer_tree_host_impl.cc(2248)] Forcing zero-copy tile initialization as worker context is missing
base::SimpleThread::ThreadMain()
#12 0x5d506c4fd626 cc::SingleThreadTaskGraphRunner::RunTaskWithLockAcquired()
#10 0x60d39d720ff0 base::(anonymous namespace)::ThreadFunc()
#13 0x75963fc0c578 <unknown>
#14 0x75963e9376dd clone

I get the same failure when running autotest desktopui_MashLogin.

This is probably the source of all the HWTest failures in the lab, so the issue is probably ~3 weeks old.

 Issue 703814  has been merged into this issue.

I made a mistake, the board in the original description was samus (Chromebook Pixel 2015, Broadwell) not link.

I cannot repro on link with Chrome 59.0.3041.0.

However, I still think this is worth tracking down, since we're going to have to fix it eventually, and it is blocking me being able to put our autotest back in the Chrome OS CQ/PFQ.

Maybe you can temporarily add samus to the list of boards to skip?
https://cs.corp.google.com/chromeos_public/src/third_party/autotest/files/client/site_tests/desktopui_MashLogin/desktopui_MashLogin.py?l=29-30

I suspect it is crashing on many boards, https://wmatrix.googleplex.com/unfiltered?hide_missing=True&releases=tot&tests=desktopui_MashLogin&days_back=1

Any updates on this? It would be great if we could get the test actually passing again.

I just verified this still happens on samus with ToT chrome r460396 (today) and canary test image OS 9411.0.0 (today). I don't think it's related to chrome vs. chrome os version skew.

Luckily it's easy to repro.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/74d8cb5db7109d9f5426136662b6dd614494c545

commit 74d8cb5db7109d9f5426136662b6dd614494c545
Author: rjkroege <rjkroege@chromium.org>
Date: Fri Apr 14 03:17:18 2017

Always create ClientNativePixmapFactory in chrome --mash

With the enabling of the --enable-native-gpu-memory-buffers on
selected ChromeOS devices where the combination of kernel and graphics
hardware permit it, every Chrome process attempting to rastersize
requires an ozone gfx::ClientNativePixmapFactory instance or it will
crash when first attempting to allocate a graphics buffer.

Given that aura is the standard mus client library for non-renderer processes
and is assumed by all ozone platforms, modify aura::Env to create such an
instance and resolve the situation where chrome --mash fails on selected
ChromeOS devices.

BUG= 704169 

Review-Url: https://codereview.chromium.org/2803523002
Cr-Commit-Position: refs/heads/master@{#464666}

[modify] https://crrev.com/74d8cb5db7109d9f5426136662b6dd614494c545/content/browser/browser_main_loop.cc
[modify] https://crrev.com/74d8cb5db7109d9f5426136662b6dd614494c545/ui/aura/env.cc
[modify] https://crrev.com/74d8cb5db7109d9f5426136662b6dd614494c545/ui/aura/env.h
[modify] https://crrev.com/74d8cb5db7109d9f5426136662b6dd614494c545/ui/gfx/client_native_pixmap_factory.cc
[modify] https://crrev.com/74d8cb5db7109d9f5426136662b6dd614494c545/ui/gfx/client_native_pixmap_factory.h