org.chromium.android_webview.test.SafeBrowsingTest#testSafeBrowsingProceedThroughInterstitialForMainFrame with {--webview-sandboxed-renderer} (CRASHED)

The flakes are recent (within the last day).

https://codereview.chromium.org/2928033002 touches both android_webview and safe_browsing, and landed shortly (~3h) before the first flakes appeared.

Assigning to Łukasz to PTAL.

assigned--> remove from sheriff queue.

It is rather painful to extract the callstack of the crash from Android bots (I've starred both  issue 657040  and  issue 631213 ), but I've managed to see the crash by

1) looking at "shard #0 isolated out" substep of the failing "webview_instrumentation_test_apk (with patch) on Android" step in https://build.chromium.org/p/tryserver.chromium.android/builders/android_n5x_swarming_rel/builds/206358 - this is https://isolateserver.appspot.com/browse?namespace=default-gzip&hash=a36fbb27bddce27feed1039fcd95598c59676f36

2. Searching for "tombstone" and getting the following link: https://luci-logdog.appspot.com/v/?s=chromium%2Fandroid%2Fswarming%2Flogcats%2F36ec9b1697827e11%2F%2B%2Ftombstones_20170623T071749-UTC_006aaadfd9c82277


The tombstone indicates that the crash happened because of the check below:

    [FATAL:layer_tree_host_impl.cc(393)] Check failed: !pending_tree_raster_duration_timer_. 

This check corresponds to:

    void LayerTreeHostImpl::UpdateSyncTreeAfterCommitOrImplSideInvalidation() 
      ...
    
      if (!did_prepare_tiles) {
        NotifyReadyToActivate();
    
        // Ensure we get ReadyToDraw signal even when PrepareTiles not run. This
        // is important for SingleThreadProxy and impl-side painting case. For
        // STP, we commit to active tree and RequiresHighResToDraw, and set
        // Scheduler to wait for ReadyToDraw signal to avoid Checkerboard.
        if (CommitToActiveTree())
          NotifyReadyToDraw();
      } else if (!CommitToActiveTree()) {
        DCHECK(!pending_tree_raster_duration_timer_);  <--- THIS CRASHES / FAILS.
        pending_tree_raster_duration_timer_ =
            base::MakeUnique<PendingTreeRasterDurationHistogramTimer>();
      }
    }

Unfortunately, looking at the tombstone, I don't see any callstack rames corresponding to LayerTreeHostImpl::UpdateSyncTreeAfterCommitOrImplSideInvalidation :-(

FWIW, I see that the failing DCHECK was added in r481685 by khushalsagar@ on Thu Jun 22 22:02:03 2017.

khushalsagar@, could you PTAL?  Since r481685 is a relatively small CL, I wonder if we might want to just revert this CL and monitor the flakiness dashboard.

#5: The result_details link makes those logs a bit easier to find. For that step, it points to https://storage.cloud.google.com/chromium-result-details/html/webview_instrumentation_test_apk_android_n5x_swarming_rel_206358_2017_06_23_T07_29_44-UTC