Which create note UI are you talking about? Lock screen, keep app, android app, or some other chrome extension app?

Oops sorry for not being specific :) The one opened via "Create note" in stylus tools.

This actually seems to be an issue with graphics/overlays

We get an error when trying to flip two planes

(gdb)  print planes.__begin_[0]
$50 = {buffer = {ptr_ = 0x521b3165580}, z_order = 0, plane_transform = (anonymous namespace)::OVERLAY_TRANSFORM_NONE, display_bounds = {origin_ = {x_ = 0, y_ = 0}, size_ = {width_ = 2400, height_ = 1600}}, crop_rect = {origin_ = {x_ = 0, y_ = 0}, size_ = {static kTrivial = 9.53674316e-07, width_ = 1, height_ = 1}}, fence_fd = -1}

(gdb)  print planes.__begin_[1]
$51 = {buffer = {ptr_ = 0x521b4064880}, z_order = 1, plane_transform = (anonymous namespace)::OVERLAY_TRANSFORM_NONE, display_bounds = {origin_ = {x_ = 698, y_ = 512}, size_ = {width_ = 1004, height_ = 646}}, crop_rect = {origin_ = {x_ = 0, y_ = 0}, size_ = {static kTrivial = 9.53674316e-07, width_ = 1, height_ = 1}}, fence_fd = -1}

+ people

Did anything change wrt overlays on eve in M65?

This goes back pretty far. In M-63 same steps cause a GPU hang instead of a crash. M-62 neither hangs no crashes.

Dave, can you take a look?

The hang in M63 started at

commit cefb285b7c7933eff34c694e8384e9c7ceb6781c (HEAD)
Author: wutao <wutao@chromium.org>
Date:   Mon Oct 9 19:25:41 2017 +0000

    CrOS: Only caching render surface when there is an opacity animation.
    
    When there is an opacity for a hierarchy of layers, it requires that a
    render surface (RS) is created to produce correct output. In this case,
    caching RS is always a benefit as we need a RS anyhow and it just avoids
    having to recreate it from the hierarchy of layers each frame of the
    animation.
    
    the layer with opacity animation.
    
    Bug:  756695 
    Test: Tested in cross fade animation, only cached render surface of
    Change-Id: Ia01e04954b69207530556569cf6f5770a0dc021b
    Reviewed-on: https://chromium-review.googlesource.com/703917
    Reviewed-by: David Reveman <reveman@chromium.org>
    Reviewed-by: Mitsuru Oshima <oshima@chromium.org>
    Commit-Queue: Tao Wu <wutao@chromium.org>
    Cr-Commit-Position: refs/heads/master@{#507444}

#9, The first cl to cache render surface in CrossFadeAnimation animation is this cl: https://chromium-review.googlesource.com/c/chromium/src/+/619931

I do not see obvious change in the cl mentioned in #9 will cause problem. Is it possible other underlining GPU changes in M63 triggers the GPU hang?

Sure. Although it only reproduces as of cefb285b7c7933eff34c694e8384e9c7ceb6781c, root cause may be something else.

Possible it's a dupe of bug 797137, I need to test again with the fix to that one.

Hi spang@, could you please put the repro steps here. Thanks!

Click the maximize button a few times. Usually the 2nd click will crash.

(of the note taking UI opened from stylus tools -> "create note")

I tested at HEAD again, still crashes as of fa58702af161fff240ab4e8c91b368761f4f6df1

This patch from wutao@ applied to HEAD (fa58702af161fff240ab4e8c91b368761f4f6df1) makes the crash significantly harder to reproduce, but does not completely fix it (varies, but can take dozens of maximize, unmaximize cycles instead of usually just 2)

Suspect cefb285b7c7933eff34c694e8384e9c7ceb6781c just started tickling the overlay code differently, making a latent issue very reproducible.

diff --git a/ash/wm/window_animations.cc b/ash/wm/window_animations.cc
index 232a16ebf9417..6f7c9cdb91d8e 100644
--- a/ash/wm/window_animations.cc
+++ b/ash/wm/window_animations.cc
@@ -347,12 +347,7 @@ base::TimeDelta CrossFadeAnimation(
     settings.SetTweenType(tween_type);
     // Only add reporter to |old_layer|.
     settings.SetAnimationMetricsReporter(g_reporter_cross_fade.Pointer());
-    settings.DeferPaint();
     if (old_on_top) {
-      // Only caching render surface when there is an opacity animation and
-      // multiple layers.
-      if (!old_layer->children().empty())
-        settings.CacheRenderSurface();
       // The old layer is on top, and should fade out.  The new layer below will
       // stay opaque to block the desktop.
       old_layer->SetOpacity(kWindowAnimation_HideOpacity);
@@ -392,12 +387,7 @@ base::TimeDelta CrossFadeAnimation(
     ui::ScopedLayerAnimationSettings settings(new_layer->GetAnimator());
     settings.SetTransitionDuration(duration);
     settings.SetTweenType(tween_type);
-    settings.DeferPaint();
     if (!old_on_top) {
-      // Only caching render surface when there is an opacity animation and
-      // multiple layers.
-      if (!new_layer->children().empty())
-        settings.CacheRenderSurface();
       // New layer is on top, fade it in.
       new_layer->SetOpacity(kWindowAnimation_ShowOpacity);
     }

Thank you spang@ to test this.

I can take a look at this when I get back to NYC on Monday. I don't think the caching of render surfaces is related as we always composite render surface using the gpu. Probably just happens that this change made it easier to repro.