Bisect gives this range https://chromium.googlesource.com/chromium/src/+log/d1cd84fc98cb4247c918630374f03eeb65182a74..08b74323568c102885a43073f95765b53f700ab8

From the bisect range , possible suspect : https://chromium.googlesource.com/chromium/src/+/4950173d4782941bd49f90be89c1d77422e8ca73

Assigning to Stanislav for further updates.

olegmax@yandex-team.ru, is there a crash report ID from chrome://crashes?

Nope, there isn't any crash report. There are a number of repeating messages like this in about:gpu:
[8004:11492:0602/110202.228:ERROR:gles2_cmd_decoder.cc(15630)] : Context lost because SwapBuffers failed.
[8004:11492:0602/110202.228:ERROR:gles2_cmd_decoder.cc(5306)] : Error: 5 for Command kPostSubBufferCHROMIUM
[8004:11492:0602/110202.228:ERROR:gpu_channel_manager.cc(188)] : Exiting GPU process because some drivers cannot recover from problems.

I could repro this on Windows 7 but not on Windows 10.
I doubt this is caused by my change because most of the code I added is turned off on Windows 7. I am going to further investigate this today.

+ halliwell@chromium.org. I wonder if the following change could be related:
https://chromium.googlesource.com/chromium/src/+/55723a7098ece4916d203986b5f7d336a0c0a9f5

It is in the same mentioned in comment #1 above.

The patch in #5 landed in M58. Tagging an RB label for M60 for tracking purpose.

I don't have a windows machine currently.  If you do, can you check behaviour with/without that CL?

The reason GPU processes crashes is because elgPostSubBufferNV returns EGL_BAD_PARAMETER because it is called with negative y from the following code:

gfx::SwapResult NativeViewGLSurfaceEGL::PostSubBuffer(int x,
                                                      int y,
                                                      int width,
                                                      int height) {
  DCHECK(supports_post_sub_buffer_);
  if (!CommitAndClearPendingOverlays()) {
    DVLOG(1) << "Failed to commit pending overlay planes.";
    return gfx::SwapResult::SWAP_FAILED;
  }
  if (flips_vertically_) {
    // With EGL_SURFACE_ORIENTATION_INVERT_Y_ANGLE the contents are rendered
    // inverted, but the PostSubBuffer rectangle is still measured from the
    // bottom left.
    y = GetSize().height() - y - height;
  }
  if (!eglPostSubBufferNV(GetDisplay(), surface_, x, y, width, height)) {
    DVLOG(1) << "eglPostSubBufferNV failed with error "
             << GetLastEGLErrorString();
    return gfx::SwapResult::SWAP_FAILED;
  }
  return gfx::SwapResult::SWAP_ACK;
}

flips_vertically_ flag is true so y gets adjusted above and ends up being negative. 
This definitely has nothing to do with my change.

I'll see if I can undo the CL I mentioned in comment #5 and if that resolves the issue.

Yes, it seems that reverting https://chromium.googlesource.com/chromium/src/+/55723a7098ece4916d203986b5f7d336a0c0a9f5 seems to fix the issue. Although I should mention that there were a lot of conflicts when I tried to revert that change locally and I am not sure if I resolved all of them correctly. But at least the GPU process stopped crashing.

Just to reiterate some of earlier comments, the issue is that the minimized popup windows makes SwapBuffers fail with EGL_BAD_PARAMETER because its y argument is negative. And that seems to make GPU process terminate - not crash but terminate deliberately.

Assigning to halliwell@chromium.org for further investigation.

Thanks for the update. Requesting halliwell@ to investigate further. The bug is tagged as RBS so please have a fix ASAP. 

Now have a windows 7 machine where I can reproduce the bug.  Will be OOO the rest of this week, will debug next week.

halliwell@ could you please look into this issue as it is marked as stable blocker.

Thanks,

So: the CL in question does change behaviour in that it now calls PostSubBuffer with full surface size, whereas before it would call regular swap in the case where swap rect == surface size.  It should be straightforward to restore the old behaviour, I can submit a CL for that.


However ... it doesn't seem like that _should_ cause the bug.  There is something else I don't understand going on in NativeViewSurfaceEGL.  Using specific dimensions from my test runs:
1) Surface is created with dimensions 160x27
2) Surface is resized to 945x1020
3) PostSubBuffer is called with (0,0,945,1020)
4) flips_vertically_ is true.  But GetSize().height() returns 27.  So now the y calculation is wrong.

jbauman: do you understand this sequence?  Why is eglQuerySurface(EGL_HEIGHT) returning the old height after a resize?  If this can be incorrect in general after a resize, it seems like PostSubBuffer could fail in a number of other situations, not just this one?

jbauman@ - Gentle Ping...!!
Could you please provide any update on the issue.

Thanks...!!

kbr: is that the right bug numbers?  (I don't follow the connection)
Also, can you help find someone to answer my question in comment 15 ... ?

halliwell: those are the bug IDs referenced by crrev.com/368450 referenced by https://chromium-review.googlesource.com/c/566382/ .

Sorry, I don't know the answer for #15.

Any updates?  M60 is going to stable next week, if a fix is going in it needs to be available for merge review this week.

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

commit 9a88c37b984954b63baba91a9434c5d7ac5f5d44
Author: John Bauman <jbauman@chromium.org>
Date: Wed Jul 19 14:59:04 2017

Re-enable use of EGL_ANGLE_window_fixed_size

This was accidentally disabled in r368450, so it was causing issues
when the window was minimized and its size doesn't match what chrome is
expecting.

Bug:  728717 
Change-Id: Ie88148b76d6391c55bf10b70cd0be481b972eb9d
Reviewed-on: https://chromium-review.googlesource.com/566382
Commit-Queue: John Bauman <jbauman@chromium.org>
Reviewed-by: Kenneth Russell <kbr@chromium.org>
Reviewed-by: Sadrul Chowdhury <sadrul@chromium.org>
Cr-Commit-Position: refs/heads/master@{#487866}
[modify] https://crrev.com/9a88c37b984954b63baba91a9434c5d7ac5f5d44/ui/gl/BUILD.gn
[modify] https://crrev.com/9a88c37b984954b63baba91a9434c5d7ac5f5d44/ui/gl/DEPS
[modify] https://crrev.com/9a88c37b984954b63baba91a9434c5d7ac5f5d44/ui/gl/gl_surface_egl.cc
[modify] https://crrev.com/9a88c37b984954b63baba91a9434c5d7ac5f5d44/ui/gl/gl_surface_egl_unittest.cc

jbauman@ - Could you please provide any update on the issue.

Thanks...!!

This regressed before M60, so I don't think we need this as a releaseblock for that.

[Auto-generated comment by a script] We noticed that this issue is targeted for M-61; it appears the fix may have landed after branch point, meaning a merge might be required. Please confirm if a merge is required here - if so add Merge-Request-61 label, otherwise remove Merge-TBD label. Thanks.

M61 branched at #488528 so CL listed at #21 is already in M61.