I believe the problem in SoftwareTextureLayerLoseFrameSinkTest is the following. Each time cc::Scheduler::OnBeginImplFrameDeadline() runs it advances the test with SoftwareTextureLayerLoseFrameSinkTest::DidCommitAndDrawFrame(). On the second call to  SoftwareTextureLayerLoseFrameSinkTest::DidCommitAndDrawFrame() it will destroy the TestLayerTreeFrameSink and replace it with a new one. If cc::Scheduler::OnBeginImplFrameDeadline() gets PostTasked to directly (I believe it comes from ScrollbarAnimationController) then everything works fine. 

However the TestLayerTreeFrameSink also has a DelayBasedBeginFrameSource, if that ticks and triggers cc::Scheduler::OnBeginImplFrameDeadline() then the DelayBasedBeginFrameSource is destroyed inside it's own callstack. There are a bunch of use-after-frees when this happens.

The test has to run very slow for the DelayBasedBeginFrameSource to fire which I guess is why the failure is so rare. It won't reproduce in ASan at ToT but after adding some log statements ASan is also slow enough to hit the same use-after-free.

piman do you know what should be controlling the OnBeginFrame() in these tests exactly?

 Issue 829923  has been merged into this issue.

DelayBasedBeginFrameSource sounds like a bad idea for reproducible tests, generally, unfortunately it looks like the default.
But either way, I think if DelayBasedBeginFrameSource can get destroyed within its own callstack, this sounds like a potential problem in production, independently of the test, and has either to be fixed, or has to be resilient to that?

I don't think this is an issue with production. The problem is that TestLayerTreeFrameSink is the whole compositing stack wrapped up into one object. SoftwareTextureLayerLoseFrameSinkTest tests LayerTreeFrameSink loss and destroys TestLayerTreeFrameSink. The display frame getting generated is the signal the test uses to destroy TestLayerTreeFrameSink, but that also destroys the Display/BeginFrameSource and causes use-after-free.

The test is disabled now so I'm downgrading the priority here and assigning back to danakj.

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

commit 6dd12972bad7c598184a9d23935f467e76bad2d9
Author: danakj <danakj@chromium.org>
Date: Thu Apr 19 15:08:19 2018

cc: Fix flaky UAF in SoftwareTextureLayerLoseFrameSinkTest

The test removes the TestLayerTreeFrameSink from the LayerTreeHost,
which destroys its BeginFrameSource, Display, etc. However it was doing
this inside a method where the cc::Scheduler, BeginFrameSource, etc
are on the stack, so then it unwinds to a UAF scenario.

Fix this by PostTasking to a fresh stack for each step of the test so
the compositor is not on the stack when interacting with it.

R=kylechar@chromium.org

Bug:  829484 
Cq-Include-Trybots: luci.chromium.try:android_optional_gpu_tests_rel;master.tryserver.blink:linux_trusty_blink_rel
Change-Id: I1868d3549c8c3a2b9a9612365bd21753ad713d8e
Reviewed-on: https://chromium-review.googlesource.com/1017769
Reviewed-by: kylechar <kylechar@chromium.org>
Commit-Queue: danakj <danakj@chromium.org>
Cr-Commit-Position: refs/heads/master@{#552019}
[modify] https://crrev.com/6dd12972bad7c598184a9d23935f467e76bad2d9/cc/layers/texture_layer_unittest.cc