Findit points to http://crbug.com/2725133002 for Linux Chromium OS ASan LSan failure (memory leak) with 75% confidence.

I have a verified fix out for review: https://codereview.
chromium.org/2754863002

TL;DR: It's not a real leak in production. Will land the fix ASAP to green
the red bot.

Ah okay, thanks for the update!

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

commit 58e6cc73277d3bc9e67687df2c1dd575019d3282
Author: rockot <rockot@chromium.org>
Date: Thu Mar 16 16:36:36 2017

Mojo: Don't hold a watch context ref in SimpleWatcher posted task

In test environments it's fairly common for task runners to be
torn down without flushing posted tasks. If there's e.g. a binding
object on the test function stack that gets destroyed on unwind,
this might end up posting a SimpleWatcher notification task that
then never runs.

Currently we disambiguate watch contexts in SimpleWatcher by
retaining a ref to the Context in said notification task and comparing
to the currently known Context instance on the SimpleWatcher's thread.
This can lead to indirect leaks in the aforementioned testing scenario.

This CL instead introduces a sequence number in SimpleWatcher which is
incremented every time a new watch is started. This sequence number is
used to disambiguate notifications which might have come from a previous
watch, thus avoiding the unnecessary ref count on Context.

BUG= 702180 
R=yzshen@chromium.org

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

[modify] https://crrev.com/58e6cc73277d3bc9e67687df2c1dd575019d3282/mojo/public/cpp/system/simple_watcher.cc
[modify] https://crrev.com/58e6cc73277d3bc9e67687df2c1dd575019d3282/mojo/public/cpp/system/simple_watcher.h

Should go green once this is picked up.