I submitted a patch to the builders to enable more browser_tests for mushrome here: https://chromium-review.googlesource.com/c/604498 . Random tests (meaning the set of tests is not always consistent) trigger a DCHECK in ~GrMemoryPool. Specifically that fAllocationCnt is 0. If this DCHECK hits it means we're leaking. So, apparently we're leaking. The trace isn't particularly helpful. Here's what it looks like:

4764:4764:0808/101352.761002:INFO:GrMemoryPool.cpp(46)] Leaked IDs (in no particular order): 35
[4764:4764:0808/101352.761436:INFO:GrMemoryPool.cpp(48)] , 30
[4764:4764:0808/101352.761466:INFO:GrMemoryPool.cpp(48)] , 24
[4764:4764:0808/101352.761478:INFO:GrMemoryPool.cpp(48)] , 33
[4764:4764:0808/101352.761488:INFO:GrMemoryPool.cpp(48)] , 32
[4764:4764:0808/101352.761500:INFO:GrMemoryPool.cpp(54)] ../../third_party/skia/src/gpu/GrMemoryPool.cpp:54: fatal error: "assert(0 == fAllocationCnt)"
Received signal 6
#0 0x0000034c5c6c base::debug::StackTrace::StackTrace()
#1 0x0000034c5761 base::debug::(anonymous namespace)::StackDumpSignalHandler()
#2 0x7fb7dcd3f330 <unknown>
#3 0x7fb7dc99cc37 gsignal
#4 0x7fb7dc9a0028 abort
#5 0x000003e38f69 sk_abort_no_print()
#6 0x000003f487e1 GrMemoryPool::~GrMemoryPool()
#7 0x7fb7dc9a21a9 <unknown>
#8 0x7fb7dc9a21f5 exit
#9 0x7fb7dc987f4c __libc_start_main
#10 0x000000586c93 Received signal 4 ILL_ILLOPN 0000082d7b39

Brian from the skia team said this likely means: "GPU rasterization that hasn't yet been flushed. So if cc were to rasterize a SkPicture to a GPU-backed SkSurface but hadn't yet flushed that." Is it possible we're dropping some tasks on the floor so that when GrMemoryPool is destroyed (it's a static, so process destruction) it isn't cleaned up?

It's also worth pointing out that we seem to very rarely actually create GrMemoryPool when running browser_tests. For example, I ran all browser_tests locally in release and only triggered creation around the 3000th test. But again, this is not consistent. And rerunning the test that triggered creation did not trigger creation on subsequent runs. Here's the stack:

#0 0x7fc4d2c21d6c base::debug::StackTrace::StackTrace()
#1 0x0000022ee418 content::(anonymous namespace)::DumpStackTraceSignalHandler()
#2 0x7fc4c9a84cb0 <unknown>
#3 0x7fc4ce758701 TPoolAllocator::allocate()
#4 0x7fc4ce724593 sh::TSymbolTable::push()
#5 0x7fc4ce7220c3 sh::TCompiler::compileTreeImpl()
#6 0x7fc4ce723a5d sh::TCompiler::compile()
#7 0x7fc4ce6a6b24 gpu::gles2::ShaderTranslator::Translate()
#8 0x7fc4ce6a52ee gpu::gles2::Shader::DoCompile()
#9 0x7fc4ce6938b1 gpu::gles2::Program::CompileAttachedShaders()
#10 0x7fc4ce6932b4 gpu::gles2::Program::Link()
#11 0x7fc4ce6425f3 gpu::gles2::GLES2DecoderImpl::DoLinkProgram()
#12 0x7fc4ce61e50c gpu::gles2::GLES2DecoderImpl::HandleLinkProgram()
#13 0x7fc4ce639953 gpu::gles2::GLES2DecoderImpl::DoCommandsImpl<>()
#14 0x7fc4ce5f5908 gpu::CommandBufferService::Flush()
#15 0x7fc4ce6cb4ef gpu::InProcessCommandBuffer::FlushOnGpuThread()
#16 0x7fc4ce6cb25b gpu::InProcessCommandBuffer::ProcessTasksOnGpuThread()
#17 0x7fc4d2c22600 base::debug::TaskAnnotator::RunTask()
#18 0x7fc4d2c4967e base::MessageLoop::RunTask()
#19 0x7fc4d2c49cce base::MessageLoop::DeferOrRunPendingTask()
#20 0x7fc4d2c4a029 base::MessageLoop::DoWork()
#21 0x7fc4d2c4b4ea base::MessagePumpDefault::Run()
#22 0x7fc4d2c724d3 base::RunLoop::Run()
#23 0x7fc4d2ca4dfc base::Thread::ThreadMain()
#24 0x7fc4d2c9ebad base::(anonymous namespace)::ThreadFunc()

This is blocking enabling more tests, so it would be great if we could investigate this soonish. Fady said Sadrul or himself will investigate. I'm randomly picking Fady so that this has an owner.