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

commit 393cc78cf982dacd721f3616b0afb752d42d9c77
Author: Jonathan <jonross@chromium.org>
Date: Tue Jul 11 02:53:12 2017

Detect unavailability of font resources

font_service::FontLoader makes a sync mojom call when attempting to load fonts.

It is possible for this call to fail if the remote service manager shuts down
before the call completes.

This leaves the calling service in a bad state, where the mojom error has yet
to be received, and where there are no font resources.

In tests this has been exhibited by crashes in some services while they
attempted to perform AuraInit. This change updates PlatformFont to provide a way
to initialize the the static defaults, which returns the success state.

AuraInit is updated to consider the lack of font as a failed init. Calling
services are already set to shutdown on these failures. Allowing us to cleanly
handle this shutdown ordering issue.

TEST=mash_browser_tests

Bug:  738441 
Change-Id: I90efe768d5027885d51bc4ac8ba1de895c297f54
Reviewed-on: https://chromium-review.googlesource.com/565031
Reviewed-by: Sadrul Chowdhury <sadrul@chromium.org>
Commit-Queue: Sadrul Chowdhury <sadrul@chromium.org>
Cr-Commit-Position: refs/heads/master@{#485501}
[modify] https://crrev.com/393cc78cf982dacd721f3616b0afb752d42d9c77/ui/gfx/platform_font_linux.cc
[modify] https://crrev.com/393cc78cf982dacd721f3616b0afb752d42d9c77/ui/gfx/platform_font_linux.h
[modify] https://crrev.com/393cc78cf982dacd721f3616b0afb752d42d9c77/ui/views/mus/aura_init.cc

This appears to have uncovered a similar issue but with ash::Shell::Init

> [0710/191201.205955:FATAL:platform_font_linux.cc(272)] Check failed: success. Could not find any font: Roboto, sans
> #0 0x00000380dbac base::debug::StackTrace::StackTrace()
> #1 0x000003826481 logging::LogMessage::~LogMessage()
> #2 0x000004abb1a7 gfx::PlatformFontLinux::InitFromDetails()
> #3 0x000004abaeea gfx::PlatformFontLinux::PlatformFontLinux()
> #4 0x000004abbf9b gfx::PlatformFont::CreateFromNameAndSize()
> #5 0x000004aae583 gfx::Font::Font()
> #6 0x000004ab2837 gfx::FontListImpl::GetFonts()
> #7 0x000004ab23b1 gfx::FontListImpl::GetHeight()
> #8 0x000004ab15dd gfx::FontList::GetHeight()
> #9 0x0000047384a7 views::Label::GetTextSize()
> #10 0x00000473837a views::Label::CalculatePreferredSize()
> #11 0x00000472bce5 views::LabelButton::Layout()
> #12 0x0000047371ef views::Label::ResetLayout()
> #13 0x00000472a397 views::LabelButton::LabelButton()
> #14 0x00000472e40a views::MdTextButton::MdTextButton()
> #15 0x00000472d89f views::MdTextButton::Create()
> #16 0x0000063f6d0f ash::LogoutButtonTray::LogoutButtonTray()
> #17 0x00000635c11e ash::StatusAreaWidget::CreateTrayViews()
> #18 0x00000633910c ash::ShelfWidget::CreateStatusAreaWidget()
> #19 0x000006329cfa ash::Shelf::CreateShelfWidget()
> #20 0x0000063244e9 ash::RootWindowController::InitLayoutManagers()
> #21 0x00000632206e ash::RootWindowController::Init()
> #22 0x0000063065ba ash::WindowTreeHostManager::InitHosts()
> #23 0x00000633b0cc ash::Shell::Init()
> #24 0x000006339d89 ash::Shell::CreateInstance()
> #25 0x000002cbbc9e ash::mus::WindowManager::CreateShell()
> #26 0x000002cbbfbe ash::mus::WindowManager::OnWmConnected()
> #27 0x0000020d68f4 ui::mojom::WindowManagerStubDispatch::Accept()
> #28 0x000004e2b0f8 mojo::InterfaceEndpointClient::HandleValidatedMessage()
> #29 0x000004e2ad96 mojo::FilterChain::Accept()
> #30 0x000004e2c295 mojo::InterfaceEndpointClient::HandleIncomingMessage()
> #31 0x000004e3339c mojo::internal::MultiplexRouter::ProcessIncomingMessage()
> #32 0x000004e32b8f mojo::internal::MultiplexRouter::Accept()
> #33 0x000004e2ad96 mojo::FilterChain::Accept()
> #34 0x000004e29339 mojo::Connector::ReadSingleMessage()
> #35 0x000004e29b51 mojo::Connector::ReadAllAvailableMessages()
> #36 0x000004e29a09 mojo::Connector::OnHandleReadyInternal()
> #37 0x000004e40f59 mojo::SimpleWatcher::OnHandleReady()
> #38 0x00000274d07f _ZN4base8internal7InvokerINS0_9BindStateIMN7content25ServiceWorkerProviderHostEFviN5blink21WebServiceWorkerStateEEJNS_7WeakPtrIS4_EEiS6_EEEFvvEE7RunImplIRKS8_RKSt5tupleIJSA_iS6_EEJLm0ELm1ELm2EEEEvOT_OT0_NS_13IndexSequenceIJXspT1_EEEE
> #39 0x0000006b62d9 _ZNO4base8CallbackIFvvELNS_8internal8CopyModeE1ELNS2_10RepeatModeE1EE3RunEv
> #40 0x0000038bee70 base::debug::TaskAnnotator::RunTask()
> #41 0x00000382e219 base::MessageLoop::RunTask()
> #42 0x00000382e4cb base::MessageLoop::DeferOrRunPendingTask()
> #43 0x00000382e8d7 base::MessageLoop::DoWork()
> #44 0x000003830eb9 base::MessagePumpLibevent::Run()
> #45 0x00000382de4b base::MessageLoop::Run()
> #46 0x000003858bca base::RunLoop::Run()
> #47 0x0000037fe8e2 (anonymous namespace)::StartEmbeddedService()
> #48 0x0000037ff11d _ZN4base8internal7InvokerINS0_9BindStateIPFvN4mojo16InterfaceRequestIN15service_manager5mojom7ServiceEEEEJEEES9_E3RunEPNS0_13BindStateBaseEOS8_
> #49 0x0000021cf61b service_manager::RunStandaloneService()
> #50 0x0000037fe50e RunMashBrowserTests()
> #51 0x0000037fe367 main
> #52 0x7f8750469f45 __libc_start_main
> #53 0x00000062634e <unknown>

The following set of gfx_unittests failed twice on recent runs of Linux ChromiumOS Tests:

gfx_unittests gfx_unittests
Run on OS: 'Ubuntu-14.04'
failures:
RenderTextHarfBuzzTest.HarfBuzz_FontListFallback/HarfBuzz
FontRenderParamsTest.SubstituteFamily
FontRenderParamsTest.MissingFamily
FontTest.LoadArial
FontRenderParamsTest.Size
FontTest.LoadArialBold
FontRenderParamsTest.UseBitmaps
FontRenderParamsTest.Style
FontRenderParamsTest.Default
FontListTest.Fonts_GetHeight_GetBaseline
RenderTextTest.StringSizeRespectsFontListMetrics/HarfBuzz
PlatformFontLinuxTest.DefaultFont
FontTest.GetActualFontNameForTesting

https://build.chromium.org/p/chromium.chromiumos/builders/Linux%20ChromiumOS%20Tests%20%28dbg%29%281%29/builds/28061
https://build.chromium.org/p/chromium.chromiumos/builders/Linux%20ChromiumOS%20Tests%20%28dbg%29%281%29/builds/28067

All failures seem to revolve around font loading.  The first failure was seen about 15 minutes after https://chromium-review.googlesource.com/#/c/565031/ landed, so suspecting this CL.  Let me know if these failures aren't related, and I'll file a separate bug.

The same failures just appeared in the release builder:
https://build.chromium.org/p/chromium.chromiumos/builders/Linux%20ChromiumOS%20Tests%20%281%29/builds/41435

and
https://build.chromium.org/p/chromium.chromiumos/builders/Linux%20ChromiumOS%20Ozone%20Tests%20%281%29/builds/49630

Also note that the dump in Comment #2 is appearing frequently as exceptions in these two builders:

https://build.chromium.org/p/chromium.chromiumos/builders/Linux%20ChromiumOS%20Tests%20%281%29
https://build.chromium.org/p/chromium.chromiumos/builders/Linux%20ChromiumOS%20Ozone%20Tests%20%281%29

So PlatformFontLinux treats the lack of fonts as a fatal error.

FontLoader tries to load fonts via a synchronous mojom call. The remote service manager can close while this call is in process. Leading to the peer closing, before onConnectionError arrives.

This failure is actually reported as a success, but without the font. See  issue 735051  for tracking the general issue that we succeed at sync calls even when the peer is closed and they fail.

Collapsing down the stack we try to use the result of the synchronous call, even though we are about to subsequently shutdown our ServiceContext once the error arrives.

However throughout Ash there is a wide number of ways in which PlatformFontLinux is accessed. I'm going to look into having a clean way to handle this error state, as having each check and try to close the ServiceContext doesn't scale.

Afterwards I'll look into FontLoader to see if there are ways we can be detect this failure, or try to reconnect.

There are two main paths which cause this:

FontListImpl::Derive which derives new fonts based on currently loaded ones. Unfortunately PlatformFontLinux uses FontLoader to try to load each of these fonts from scratch, before using skia to create a new SkTypeface. In the future we should try to see if we can just derive with the already loaded information

FontFallbackLinux::GetFallbackFonts which attempts to generate a new Font with a given font family. This doesn't try to fallback to the default if it is available.

To address the race condition we are changing the lack of font resources from being fatal. Now instead the PlatformFontLinux will fallback to the default font, and log the error.

 Issue 739824  has been merged into this issue.

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

commit 591e1f86fd0649fefa60cbcb056edcfa43cebc4e
Author: Jonathan <jonross@chromium.org>
Date: Thu Jul 13 23:32:48 2017

Have PlatformFontLinux Fallback to default

It is possible to font loading to fail. Such as when the peer closes during a
synchronous mojo call to load a font.

Currently this is treated as a fatal error, which leads to flaky tests.

This change updates PlatformFontLinux to instead fallback to providing the
default font in these cases. While logging the error.

TEST=mash_browser_tests

Bug:  738441 
Change-Id: I2717a0fdf561be82e6d393863a0cfd13b19ae480
Reviewed-on: https://chromium-review.googlesource.com/568789
Reviewed-by: Dan Erat <derat@chromium.org>
Reviewed-by: Sadrul Chowdhury <sadrul@chromium.org>
Commit-Queue: Jonathan Ross <jonross@chromium.org>
Cr-Commit-Position: refs/heads/master@{#486533}
[modify] https://crrev.com/591e1f86fd0649fefa60cbcb056edcfa43cebc4e/ui/gfx/platform_font_linux.cc

These crashes are fixed. I've filed issue 744671 to track my thoughts on the dangers of using the current FontLoader, along with how broad the entry points are.