Looks like it's likely just an uninitialized var:

namespace {
// This is a leaky bare owning pointer.
SkFontMgr* g_default_fontmgr;
}  // namespace

I will try to send up a CL if I have time. Feel free to beat me to it.

Not sure what you mean in #1, this is a raw pointer with static storage (due to being in a namespace) and is therefore implicitly nullptr. The issue here appears to be that it is actually being set more than once (which is probably useless, I'll have to check).

Interesting, this didn't happen at all at https://luci-logdog.appspot.com/v/?s=chromium%2Fbb%2Ftryserver.chromium.win%2Fwin_chromium_x64_rel_ng%2F346135%2F%2B%2Frecipes%2Fsteps%2Fbrowser_tests__with_patch_%2F0%2Fstdout when my change landed. It appears that this only happens on win10_chromium_x64_rel_ng  but not win_chromium_x64_rel_ng, what is different about that bot?

I believe the assert here probably is catching an actual issue, this is really lazy initialization of what is effectively a static global which needs to be finished before the first call to the getter (the SkFontMgr::Factory method). If it actually does need to be set more than once then the code needs to change to handle that properly (if this was happening before, it really was leaking).

Interesting, so from what I can tell ui/gfx/win/direct_write.cc#MaybeInitializeDirectWrite is getting called first and calling SetDefaultSkiaFactory. Then later content/child/dwrite_font_proxy/dwrite_font_proxy_init_win.cc#InitializeDWriteFontProxy is called which also calls SetDefaultSkiaFactory with a different SkFontMgr, which will lead to a leak, which is what the assert is catching.

The reason why this is happening on Win10 and not Win7 appears to be that the latter call is only made if the IDWriteFactory is actually an IDWriteFactory2, which is only available on Win8.1 and later. I'm not sure why this is the case.

Actually, I misread the IDWriteFactory2 code. It is not the IDWriteFactory2 test in InitializeDWriteFontProxy causing the difference.

It appears that ppapi_plugin_main.cc is doing this to itself. It conditionally calls MaybeInitializeDirectWrite first and then calls InitializeDWriteFontProxy unconditionally.

if (!base::win::IsUser32AndGdi32Available())
  gfx::win::MaybeInitializeDirectWrite();
InitializeDWriteFontProxy();

IsUser32AndGdi32Available is always true in Win7 (they can't be disabled until Win8) so on Win7 just InitializeDWriteFontProxy is called. On Win8 and later they will both be called, and both of them try to set the global.

Something of a work-around at https://codereview.chromium.org/2644103003/ . ppapi code should be updated not to need this since it's effectively creating two SkFontMgr objects and always throwing the first one away on Win8+. However, it's not clear what the right approach is and it's easy to work around for now.

Fantastic. I see that your CL has a green run on the bot. Thanks for the quick turnaround.

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

commit 5ecd69eb2b90a83d67cce615e564dcc70a2d14bb
Author: bungeman <bungeman@chromium.org>
Date: Thu Jan 19 22:28:42 2017

Allow multiple calls to SetDefaultSkiaFactory on Windows.

The ppapi code currently calls SetDefaultSkiaFactory twice on Win8+.
Previous code simply leaked an SkFontMgr and the current code asserts
(which is how this was discovered). This CL allows SetDefaultSkiaFactory
to be called more than once, properly handling the reference counting
and asserting in debug builds that SetDefaultSkiaFactory is not called
after SkFontMgr::Factory is called.

BUG= chromium:682652 

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

[modify] https://crrev.com/5ecd69eb2b90a83d67cce615e564dcc70a2d14bb/skia/ext/fontmgr_default_android.cc
[modify] https://crrev.com/5ecd69eb2b90a83d67cce615e564dcc70a2d14bb/skia/ext/fontmgr_default_win.cc