This is reproducible with Canary 63.0.3236.0 on Windows 10. It seems to only affect the first window minimized/maximized in the user's profile, for some reason. If the browser's restarted it doesn't seem to happen.

Any ideas why this might be the case?

Hi all, 

The abnormal crash of GPU process may cause memory leak and my Intel colleagues told me it has been regarded as a blocking issue for us, so could someone try to investigate it as soon as possible?

Could you explain how the GPU process crash causes a memory leak?

We need to find someone on the GPU team to take this. I can do it if there is no other Windows expert who is wiling to.

sunnyps@ could you please take a look?

I'm raising priority as this could impact some user's experience.

There is a M62 stable release next week. So marking it as 'Rb-Stable' for M62.

Hi kbr@,

One of my colleague from our driver team has found the old D3D11 device isn't destroyed after the old GPU process is destroyed as the driver doesn't receive such command, thus causing memory leak.

Thanks Jiawei for the information, but isn't the driver responsible for tearing down all Direct3D resources allocated by the process once the process exits? It shouldn't be the case that the process has to exit cooperatively in order to avoid resource leaks. This sounds like a bad bug in the driver.

Hi kbr@, 

DX11 Driver is actually controlled by DX runtime, that is to say the driver doesn't know if a process has been exited or not. The driver will only destroy the D3D11 resource if it receives the command from DX runtime.

So it is the DX runtime to be responsible for this kind of GC work.

 Issue 758936  has been merged into this issue.

This looks like a bug in our code.
+jbauman in case he can give us a hint / double-check assumptions.

Here are the 4 possible failure cases:
1- https://cs.chromium.org/chromium/src/gpu/ipc/service/direct_composition_surface_win.cc?sq=package:chromium&dr=CSs&l=1282
2- https://cs.chromium.org/chromium/src/gpu/ipc/service/direct_composition_child_surface_win.cc?sq=package:chromium&dr=CSs&l=248
3- https://cs.chromium.org/chromium/src/gpu/ipc/service/direct_composition_child_surface_win.cc?sq=package:chromium&dr=CSs&l=254
4- https://cs.chromium.org/chromium/src/gpu/ipc/service/direct_composition_child_surface_win.cc?sq=package:chromium&dr=CSs&l=258

I think #2 is out because it would have another log. #1 is probably out, I don't believe root_surface_ gets to null after it's created. It is recreated on resize though. #3 and #4 seem possible. It would indicate a bug at a higher level though (compositor side?)

The SetRect fails because the rect isn't contain correctly.  From what I see if I minimize the screen and bring it back with an empty directory the code:  bool Rect::Contains(const Rect& rect) const {
  return (rect.x() >= x() && rect.right() <= right() && rect.y() >= y() &&
          rect.bottom() <= bottom());
}

in rect.cc returns here stating Draw rectangle must be contained within size of surface.  This is the only way I am able to reproduce it is to minimize and maximize the tab.

When the browser come back from being minimized the rect has (0,0,1914,1045) and falls into the code in rect.cc line 165 that determines that the value doesn't fall into the rect. and returns error to the GPU process shutting it down and restarting from what I can see.  Again it is the only way I can reproduce it.

Seems like the issue is that the damage rect on the root render pass is larger than the surface is. Is the surface being resized to 1,1 on minimize, or is stuck at the initial size for some reason? It should be receiving an initial resize to be correct.

Yes I did see the resize to 1,1 at one point while I was trying to debug.  But it is hard to be sure since I was debugging remotely on the machine.  I will check before and when the browser goes into minimize for 1,1 and when it comes back out it is valid.  If the rect is corrupt I then at least we know that much.  Then I can look for how it gets corrupt.  Suggestions?

I suspect the issue could be on line https://cs.chromium.org/chromium/src/components/viz/service/display/direct_renderer.cc?q=DirectRenderer&sq=package:chromium&l=358
or https://cs.chromium.org/chromium/src/components/viz/service/display/direct_renderer.cc?q=DirectRenderer&sq=package:chromium&l=368
(though most likely the former).

I don't think we can assume the root render pass fits the device viewport (used for Resize) exactly, in particular we intersect the damage rect in the general case: https://cs.chromium.org/chromium/src/components/viz/service/display/direct_renderer.cc?q=DirectRenderer&sq=package:chromium&l=278

So it looks like your last comment is right that the rect isn't getting set to 1,1 then it is minimized.  At line 8948 where we start to return the rect after minimized is still 923,1009 which I think should be 1,1 in the minimized state?  So when it comes back out of the minimized state we will get the message: "Context lost because SetDrawRectangleCHROMIUM failed."  I guess the next step if you recommend is looking at where the minimized values are set?  What I don't understand is why it requires the cache to be cleared.  If the value is stored in the user data area that would make some sense to the rect area being valid.

We find the empty user data directory is one of the situation that can always reproduce this issue and  issue #758936 . 
In fact it may also be observed with a no-empty cache.  

With regard to process crashing causing memory leaks:

TL;DR: Terminating processes will not leak memory on Windows.

In Windows, the kernel tracks all objects exposed to user mode in a process handle table. When a process terminates, the handle table is walked and objects are destroyed.  If those objects have corresponding driver resources, it informs the kernel mode driver via the normal kernel destruction device driver interfaces.  

If a resource is a cross-process shared surface, it will get freed when all processes have released their references.

Thanks Rafael for confirming. Jiawei, if Intel's D3D driver is somehow leaking memory then that is a bug in the driver.

Thanks Rafael and Ken's comment, today I talked with that colleague and what he actually means is it is better to delete D3D11 device before the process exits so that the driver can destroy all the resources more gracefully. Sorry for my misunderstanding.

Today I investigated the black screen issue on Chrome 61 Release on several Intel graphics cards:
( https://crbug.com/759084 ,   https://crbug.com/761620 ,   https://crbug.com/758936 )
I found the regression happens at #471244 (https://codereview.chromium.org/2881483002).
Based on this patch I found if I removed https://cs.chromium.org/chromium/src/components/viz/service/display/direct_renderer.cc?l=302, both the black screen issue on Intel and this issue can be fixed. 
So I suppose if there is bug in #471244.

Thanks all for taking a look into it. Confirmed with sunnyps@ and this shouldn't block M62 Stable Release. 

However, we should aim to get the fix in for a future M62 respin if possible. 

M63 beta promotion is coming VERY soon. Your bug is labelled as Beta ReleaseBlock, pls make sure to land the fix and get it merged into the release branch ASAP. Thank you.

I confirmed on the machine I was able to confirm that the by just removing the did_reshape prevents stops the output_rect from replacing the root_damage_rect which allows chrome to be minimized and restored and resized without the context loss to the rect.  Could we get a confirmation on M62 respin and a possible time frame?

This bug happens when we resize a display to size zero and then try to draw a frame non-zero size. We resize to size zero to prevent swaps while the window is resizing[1]. Normally we wouldn't draw if the surface size doesn't match the display size, but we do so if we have copy output requests[2]. We've been doing things this way since 2015[3], but it breaks when using DirectComposition because we want the render pass size (SetDrawRectangleCHROMIUM) to be smaller than the window surface size (set by ResizeCHROMIUM).

[1] https://codereview.chromium.org/767443002
[2] https://cs.chromium.org/chromium/src/components/viz/service/display/display.cc?rcl=c37f22b2029987406c70d64b88939d820aa60f85&l=298
[3] https://codereview.chromium.org/938533002

We have a couple of alternatives here:
1. Don't draw until surface size despite having copy output requests.
2. Do not resize the underlying window surface when disabling swaps i.e. do not emit a ResizeCHROMIUM command.

Thoughts?

> 1. Don't draw until surface size despite having copy output requests.

If this is simpler I support this. Copy requests aren't that time sensitive generally, modulo tab capture, but during resize I think that's not a case to optimize for.

Which one is simpler do you think?

1. is definitely simpler. I think that way we avoid the window resize too as that happens inside draw.

 Issue 769398  has been merged into this issue.

Agree #1 is easier but the only concern I have is that if you were to doc a laptop and minimize chrome.  Then undock and then unminimize chrome do this fix work?  The resolutions will change with a resize and this is a typical use case?   I can try #1 and test it with this use case if you think it is useful?

#34: I already have a WIP patch for 1. The major drawback is that copy output requests will be dropped. Today, we resize the window surface to (1, 1) and then execute the original copy output request which is bonkers. Maybe it works because we create extra render targets for the copy output request?

The copy output request comes from ThumbnailTabHelper which appears to be resilient to the request failing so it should be ok to drop the request.

Stack trace:
> viz_common.dll!viz::CopyOutputRequest::CopyOutputRequest(viz::CopyOutputResult::Format result_format, base::OnceCallback<void __cdecl(std::unique_ptr<viz::CopyOutputResult,std::default_delete<viz::CopyOutputResult> >)> result_callback) Line 18 
  content.dll!std::make_unique<viz::CopyOutputRequest,enum viz::CopyOutputResult::Format,base::OnceCallback<void __cdecl(std::unique_ptr<viz::CopyOutputResult,std::default_delete<viz::CopyOutputResult> >)>,void>(viz::CopyOutputResult::Format && <_Args_0>, base::OnceCallback<void __cdecl(std::unique_ptr<viz::CopyOutputResult,std::default_delete<viz::CopyOutputResult> >)> && <_Args_1>) Line 2438  
  content.dll!content::DelegatedFrameHost::CopyFromCompositingSurface(const gfx::Rect & src_subrect, const gfx::Size & output_size, const base::RepeatingCallback<void __cdecl(SkBitmap const &,enum content::ReadbackResponse)> & callback, const SkColorType preferred_color_type) Line 135 
  content.dll!content::RenderWidgetHostViewAura::CopyFromSurface(const gfx::Rect & src_subrect, const gfx::Size & dst_size, const base::RepeatingCallback<void __cdecl(SkBitmap const &,enum content::ReadbackResponse)> & callback, const SkColorType preferred_color_type) Line 862 
  chrome.dll!ThumbnailTabHelper::AsyncProcessThumbnail(scoped_refptr<thumbnails::ThumbnailService> thumbnail_service) Line 225  
  chrome.dll!ThumbnailTabHelper::UpdateThumbnailIfNecessary() Line 188  
  chrome.dll!ThumbnailTabHelper::WidgetHidden(content::RenderWidgetHost * widget) Line 299  
  chrome.dll!ThumbnailTabHelper::Observe(int type, const content::NotificationSource & source, const content::NotificationDetails & details) Line 92  
  content.dll!content::NotificationServiceImpl::Notify(int type, const content::NotificationSource & source, const content::NotificationDetails & details) Line 128 
  content.dll!content::RenderWidgetHostImpl::WasHidden() Line 672 
  content.dll!content::RenderWidgetHostViewAura::WasOccluded() Line 708 
  content.dll!content::RenderWidgetHostViewAura::Hide() Line 539  
  content.dll!content::WebContentsImpl::WasHidden() Line 1524 
  content.dll!content::WebContentsImpl::UpdateWebContentsVisibility(bool visible) Line 5935 
  content.dll!content::WebContentsViewAura::OnWindowVisibilityChanged(aura::Window * window, bool visible) Line 1324  
  aura.dll!aura::Window::NotifyWindowVisibilityChangedAtReceiver(aura::Window * target, bool visible) Line 969  
  aura.dll!aura::Window::NotifyWindowVisibilityChangedDown(aura::Window * target, bool visible) Line 975  
  aura.dll!aura::Window::NotifyWindowVisibilityChanged(aura::Window * target, bool visible) Line 956  
  aura.dll!aura::Window::SetVisible(bool visible) Line 734  
  aura.dll!aura::Window::Hide() Line 228  
  views.dll!views::NativeViewHostAura::HideWidget() Line 189  
  views.dll!views::NativeViewHost::Layout() Line 108  
  views.dll!views::View::BoundsChanged(const gfx::Rect & previous_bounds) Line 2291 
  views.dll!views::View::SetBoundsRect(const gfx::Rect & bounds) Line 343 
  webview.dll!views::WebView::OnBoundsChanged(const gfx::Rect & previous_bounds) Line 127 
  views.dll!views::View::BoundsChanged(const gfx::Rect & previous_bounds) Line 2286 
  views.dll!views::View::SetBoundsRect(const gfx::Rect & bounds) Line 343 
  chrome.dll!ContentsLayoutManager::Layout(views::View * contents_container) Line 60  
  views.dll!views::View::Layout() Line 612  
  views.dll!views::View::BoundsChanged(const gfx::Rect & previous_bounds) Line 2291 
  views.dll!views::View::SetBoundsRect(const gfx::Rect & bounds) Line 343 
  chrome.dll!BrowserViewLayout::LayoutContentsContainerView(int top, int bottom) Line 470 
  chrome.dll!BrowserViewLayout::Layout(views::View * browser_view) Line 349 
  views.dll!views::View::Layout() Line 612  
  chrome.dll!BrowserView::Layout() Line 1951  
  views.dll!views::View::BoundsChanged(const gfx::Rect & previous_bounds) Line 2291 
  views.dll!views::View::SetBoundsRect(const gfx::Rect & bounds) Line 343 
  views.dll!views::NonClientView::Layout() Line 178 
  views.dll!views::View::BoundsChanged(const gfx::Rect & previous_bounds) Line 2291 
  views.dll!views::View::SetBoundsRect(const gfx::Rect & bounds) Line 343 
  views.dll!views::FillLayout::Layout(views::View * host) Line 20 
  views.dll!views::View::Layout() Line 612  
  views.dll!views::View::BoundsChanged(const gfx::Rect & previous_bounds) Line 2291 
  views.dll!views::View::SetBoundsRect(const gfx::Rect & bounds) Line 343 
  views.dll!views::View::SetBounds(int x, int y, int width, int height) Line 321  
  views.dll!views::View::SetSize(const gfx::Size & size) Line 349 
  views.dll!views::Widget::OnNativeWidgetSizeChanged(const gfx::Size & new_size) Line 1119  
  views.dll!views::DesktopNativeWidgetAura::OnHostResized(aura::WindowTreeHost * host) Line 1168  
  aura.dll!aura::WindowTreeHost::OnHostResizedInPixels(const gfx::Size & new_size_in_pixels) Line 347 
  views.dll!views::DesktopWindowTreeHostWin::HandleClientSizeChanged(const gfx::Size & new_size) Line 822 
  views.dll!views::HWNDMessageHandler::ClientAreaSizeChanged() Line 1210  
  views.dll!views::HWNDMessageHandler::OnWindowPosChanged(tagWINDOWPOS * window_pos) Line 2516  
  views.dll!views::HWNDMessageHandler::_ProcessWindowMessage(HWND__ * hWnd, unsigned int uMsg, unsigned int wParam, long lParam, long & lResult, unsigned long dwMsgMapID) Line 453 
  views.dll!views::HWNDMessageHandler::OnWndProc(unsigned int message, unsigned int w_param, long l_param) Line 942 
  gfx.dll!gfx::WindowImpl::WndProc(HWND__ * hwnd, unsigned int message, unsigned int w_param, long l_param) Line 304  
  gfx.dll!base::win::WrappedWindowProc<&gfx::WindowImpl::WndProc>(HWND__ * hwnd, unsigned int message, unsigned int wparam, long lparam) Line 76  
  [External Code]   Annotated Frame
  views.dll!views::HWNDMessageHandler::OnSysCommand(unsigned int notification_code, const gfx::Point & point) Line 2281 
  views.dll!views::HWNDMessageHandler::_ProcessWindowMessage(HWND__ * hWnd, unsigned int uMsg, unsigned int wParam, long lParam, long & lResult, unsigned long dwMsgMapID) Line 450 
  views.dll!views::HWNDMessageHandler::OnWndProc(unsigned int message, unsigned int w_param, long l_param) Line 942 
  gfx.dll!gfx::WindowImpl::WndProc(HWND__ * hwnd, unsigned int message, unsigned int w_param, long l_param) Line 304  
  gfx.dll!base::win::WrappedWindowProc<&gfx::WindowImpl::WndProc>(HWND__ * hwnd, unsigned int message, unsigned int wparam, long lparam) Line 76  
  [External Code]   Annotated Frame
  views.dll!views::HWNDMessageHandler::OnWndProc(unsigned int message, unsigned int w_param, long l_param) Line 948 
  gfx.dll!gfx::WindowImpl::WndProc(HWND__ * hwnd, unsigned int message, unsigned int w_param, long l_param) Line 304  
  gfx.dll!base::win::WrappedWindowProc<&gfx::WindowImpl::WndProc>(HWND__ * hwnd, unsigned int message, unsigned int wparam, long lparam) Line 76  
  [External Code]   Annotated Frame
  base.dll!base::MessagePumpForUI::ProcessMessageHelper(const tagMSG & msg) Line 365  
  base.dll!base::MessagePumpForUI::ProcessNextWindowsMessage() Line 339 
  base.dll!base::MessagePumpForUI::DoRunLoop() Line 169 
  base.dll!base::MessagePumpWin::Run(base::MessagePump::Delegate * delegate) Line 58  
  base.dll!base::MessageLoop::Run() Line 345  
  base.dll!base::RunLoop::Run() Line 121  
  chrome.dll!ChromeBrowserMainParts::MainMessageLoopRun(int * result_code) Line 1921  
  content.dll!content::BrowserMainLoop::RunMainMessageLoopParts() Line 1205 
  content.dll!content::BrowserMainRunnerImpl::Run() Line 141  
  content.dll!content::BrowserMain(const content::MainFunctionParams & parameters) Line 46  
  content.dll!content::RunNamedProcessTypeMain(const std::basic_string<char,std::char_traits<char>,std::allocator<char> > & process_type, const content::MainFunctionParams & main_function_params, content::ContentMainDelegate * delegate) Line 429 
  content.dll!content::ContentMainRunnerImpl::Run() Line 707  
  content.dll!content::ContentServiceManagerMainDelegate::RunEmbedderProcess() Line 52  
  embedder.dll!service_manager::Main(const service_manager::MainParams & params) Line 453 
  content.dll!content::ContentMain(const content::ContentMainParams & params) Line 19 
  chrome.dll!ChromeMain(HINSTANCE__ * instance, sandbox::SandboxInterfaceInfo * sandbox_info, __int64 exe_entry_point_ticks) Line 123 
  chrome.exe!MainDllLoader::Launch(HINSTANCE__ * instance, base::TimeTicks exe_entry_point_ticks) Line 199  
  chrome.exe!wWinMain(HINSTANCE__ * instance, HINSTANCE__ * prev, wchar_t * __formal, int __formal) Line 230  
  [External Code]   Annotated Frame

To answer the question about docking and undocking, those cases should work fine.

To clarify,

Draw = resize the surface (ResizeCHROMIUM), draws render passes (in DirectComposition path, calls SetDrawRectangleCHROMIUM before issuing commands for drawing)

Swap = swap buffers (in DirectComposition, call ScheduleDCOverlayCHROMIUM)

Today, if surface size (the last render pass' output size) doesn't match display size (current_surface_size_ in Display) and we have an copy output request, we do Draw but not Swap. Before DirectComposition Draw would be fine because there was no SetDrawRectangle call.

The proposal is to skip both Draw and Swap when the sizes don't match. This means dropping copy output requests.

With my fix, the thumbnail copy output request fails every time the window is minimized. I don't think we want that either.

If we know we're going to draw and not swap, we could draw to a FBO (like non-root render passes) instead of the window - so we can skip SetDrawRectangleCHROMIUM, and we don't need to resize anything. We would just need to make sure we deal with damage properly (we need to redraw the entire FBO instead of just the damage rect, and we shouldn't consider the area that we drew to patch the window damage).

Copy requests dont go to the actual window anyway. In this case we wouldn't be drawing to the window at all, so the resize isn't needed.

However if we can early out sooner, before we collect (and thus drop) copy requests that'd be nice?

Please have the fix ready & merged in to M63 branch by the end of this week.
This is marked as a Beta Blocker and M63 is scheduled to be promoted to Beta channel next week 10/23.

 Issue 776546  has been merged into this issue.

Brain dump:

1. Why do we disable swap for resize?

On Windows, we get two messages when a window is moved or resized: WindowPosChanging and WindowPosChanged. In between these two messages, windows does a bunch of things like paint the non client area (window decorations).

With D3D11, rendering and buffer swaps are asynchronous with respect to resize so windows will stretch the output to fit the window. It's not clear why it stretches newly swapped buffers and not the existing contents of the window. And is different with DirectComposition?

piman@ suggested that we need to resize the window to (0,0) and not just prevent swaps but I don't think that's correct. We resize the window *only* if we draw with zero size. We won't draw with zero size unless there are copy output requests. Also, local experimentation suggests that the resize isn't needed and even if we resize it's to (1,1) as we use max(1, width/height) in the gpu process.

2. Why do we finish pending swaps on resize?

Just disabling swaps is not enough as there may be pending swaps in flight. Calling finish ensures that all pending commands are executed in the gpu process.

3. DirectComposition requirements.

With DirectComposition, we have a DirectCompositionSurfaceWin instance which manages a two-level tree of DirectCompositionChildSurfaceWin instances. The surfaces are backed by either a native DC surface or a D3D11 swap chain.

When drawing to the DC surface, we must specify the area we're going to draw to ahead of time, and do all drawing between BeginDraw/EndDraw calls. Furhtermore, we must damage the entire area after a resize to prevent flickering.

The root render pass draws to the root surface, and so it calls SetDrawRectangle every frame with its damage rect.

 Issue 761620  has been merged into this issue.

This doesn't need to block beta.

I have a fix but that's causing less than full damage after resize which breaks another DirectComposition requirement.

 Issue 776904  has been merged into this issue.

 Issue 776904  shows that this can happen more often than just with a fresh user profile. Repro steps:

1) Close and reopen Chrome Stable (62)
2) Open a new window
3) Navigate to  http://crbug.com/776904 
4) Control-click the ap.org link to open it in a new tab
5) Minimize that window

The GPU process will crash because of the SetDrawRectangle failure.

 Issue 763835  has been merged into this issue.

 Issue 763835  shows it can happen on navigating PDF files.
Repro steps:

1) Close and reopen Chrome Stable (62)
2) Open a new window
3) Navigate http://che.org.il/wp-content/uploads/2016/12/pdf-sample.pdf (referred in  http://crbug.com/763835 )
   You can see the pdf document.
4) Minimize the window
5) Maximize the window

You will see a blank page after maximizing the window because the GPU process crashes for the SetDrawRectangle failure.

 Issue 777171  has been merged into this issue.

hello developers!!

many users in this recntly 3 month had this problem!

please see this post in Intel support:

https://communities.intel.com/message/495882

Hi all,
i'm following this discussion as i'm affected by this bug. I have an intel hd 630.

Anyway i've noticed that the bug has been introduced since the version 59 of chromium/chrome.
In fact at the moment i've reverted back to version 58.0.3029.110 and the bug is gone.

I've noticed that using an old intel driver (21.20.16.4664) and any chromium version grater than 58.0.3029.110 the bug is not happening.

While if i use any intel driver grater than 21.20.16.4664 and any chromium version gt 58 the bug is there.

hope this may be useful.

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

commit 6015a99b8843d7eceea6868d7a83166007e8bf89
Author: Sunny Sachanandani <sunnyps@chromium.org>
Date: Wed Oct 25 01:20:33 2017

viz: Do not use root render pass size in lieu of output surface size.

On Windows with Direct Composition enabled, we want to set the root
damage rect to the output surface (display) size after a resize, but use
the root render pass output rect instead. The output surface size may
differ from root render pass output size because rendering is
asynchronous with respect to resize.

Futhermore, we disable swaps in between the WindowPosChanging and
WindowPosChanged messages (DisableSwapUntilResize) by setting display
size to zero. We normally skip drawing in flight compositor frames
because the display and surface sizes don't match. However, if copy
output requests are present we try to draw and fail in SetDrawRectangle
because the damage is calculated from root render pass output rect which
is larger than display size of zero.

This manifested in a GPU process crash on minimizing the window in the
presence of a copy output request from the thumbnail helper.

R=piman,danakj
BUG= 773199 
TEST=GLRendererPartialSwapTest.SetDrawRectangle*

Change-Id: I5a037de38866a64bcd83a04a9b9dca9e682a2454
Reviewed-on: https://chromium-review.googlesource.com/734170
Commit-Queue: Sunny Sachanandani <sunnyps@chromium.org>
Reviewed-by: Antoine Labour <piman@chromium.org>
Reviewed-by: danakj <danakj@chromium.org>
Reviewed-by: ccameron (ping after 24hr) <ccameron@chromium.org>
Cr-Commit-Position: refs/heads/master@{#511328}
[modify] https://crrev.com/6015a99b8843d7eceea6868d7a83166007e8bf89/components/viz/service/display/direct_renderer.cc
[modify] https://crrev.com/6015a99b8843d7eceea6868d7a83166007e8bf89/components/viz/service/display/gl_renderer_unittest.cc
[modify] https://crrev.com/6015a99b8843d7eceea6868d7a83166007e8bf89/components/viz/service/display/overlay_unittest.cc

 Issue 777735  has been merged into this issue.

I have verified the fix in #52 can solve this bug. Thanks for your fix!

Will this fix be merged into M62 or M63 branch? Since a large number of customers are suffering from this bug, they really want to get the fix as soon as possible.

I'll request a merge to M63 once this lands on canary. Then we can decide if this should go in M62 stable refresh.

Fixed in 64.0.3250.0. Requesting a merge to M63.

This bug requires manual review: M63 has already been promoted to the beta branch, so this requires manual review
Please contact the milestone owner if you have questions.
Owners: cmasso@(Android), cmasso@(iOS), gkihumba@(ChromeOS), govind@(Desktop)

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Approving merge to M63 branch 3239 based on comment #54 and #56. Please merge ASAP. Thank you.

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

commit 5c4373825747efd8761c990a92b33549c294e1a3
Author: Sunny Sachanandani <sunnyps@chromium.org>
Date: Thu Oct 26 21:54:35 2017

viz: Do not use root render pass size in lieu of output surface size.

On Windows with Direct Composition enabled, we want to set the root
damage rect to the output surface (display) size after a resize, but use
the root render pass output rect instead. The output surface size may
differ from root render pass output size because rendering is
asynchronous with respect to resize.

Futhermore, we disable swaps in between the WindowPosChanging and
WindowPosChanged messages (DisableSwapUntilResize) by setting display
size to zero. We normally skip drawing in flight compositor frames
because the display and surface sizes don't match. However, if copy
output requests are present we try to draw and fail in SetDrawRectangle
because the damage is calculated from root render pass output rect which
is larger than display size of zero.

This manifested in a GPU process crash on minimizing the window in the
presence of a copy output request from the thumbnail helper.

R=danakj, piman
TBR=sunnyps@chromium.org
BUG= 773199 
TEST=GLRendererPartialSwapTest.SetDrawRectangle*

(cherry picked from commit 6015a99b8843d7eceea6868d7a83166007e8bf89)

Change-Id: I5a037de38866a64bcd83a04a9b9dca9e682a2454
Reviewed-on: https://chromium-review.googlesource.com/734170
Commit-Queue: Sunny Sachanandani <sunnyps@chromium.org>
Reviewed-by: Antoine Labour <piman@chromium.org>
Reviewed-by: danakj <danakj@chromium.org>
Reviewed-by: ccameron (ping after 24hr) <ccameron@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#511328}
Reviewed-on: https://chromium-review.googlesource.com/740661
Reviewed-by: Sunny Sachanandani <sunnyps@chromium.org>
Cr-Commit-Position: refs/branch-heads/3239@{#254}
Cr-Branched-From: adb61db19020ed8ecee5e91b1a0ea4c924ae2988-refs/heads/master@{#508578}
[modify] https://crrev.com/5c4373825747efd8761c990a92b33549c294e1a3/components/viz/service/display/direct_renderer.cc
[modify] https://crrev.com/5c4373825747efd8761c990a92b33549c294e1a3/components/viz/service/display/gl_renderer_unittest.cc
[modify] https://crrev.com/5c4373825747efd8761c990a92b33549c294e1a3/components/viz/service/display/overlay_unittest.cc

thanks for fixing this issue. I hope it will also be merged to m62 stable. 

 Issue 759084  has been merged into this issue.

Will this fix go in M62 stable refresh?

sunnyps@ can you please confirm if we need to merge this for M62 as well?

The fix hasn't rolled into beta yet. Don't we want it to bake in beta for a while before merging to M62?

[Bulk Edit]
URGENT - PTAL.
M63 Stable promotion is coming soon and your bug is labelled as Stable ReleaseBlock, pls make sure to land the fix and get it merged into the release branch ASAP. Thank you.

There is a potential issue that has been noted that could be a side effect of this fix.  When playing videos the video is black using RS3.  When you mouse over the video the video becomes visible.  I haven't duplicated this issue yet as I haven't set up the environment to duplicate this but a sighting by others has been reported in the latest canary build. 

 Issue 780054  has been merged into this issue.

#66 can you please file a bug for that with repro steps and cc me? Thanks!

sunnyps@, based on comment #66 there is a side effect of this fix. Would it be ok to revert this change from M63? This bug exists on current stable M62 so we can leave with it for M63 as well. What do you think?

RS3 is Fall Creators Update right? #66: Issue 775898 seems to be related.

#69: There's no confirmation of the fix here causing issues. Do you know of any bugs filed about that?

#70: Sorry I misunderstood comment #66. If there is no confirmation of the fix here causing issue, then it is fine to leave it in M63.

 Issue 780836  has been merged into this issue.

 Issue 781125  has been merged into this issue.

 Issue 781385  has been merged into this issue.

This has made it to beta. Haven't heard of any issues except #66 which is unconfirmed. Requesting merge to stable.

My recommendation is to target this fix for M63. We are already ramping up M62 and our release candidate has been finalized for respin. Unless this is an absolute critical P0 bug, rejecting merge for M62. If you disagree, please re-request merge with full justification for why this is critical. 

M63 Stable promotion is coming soon and your bug is labelled as Stable ReleaseBlock, pls make sure to land the fix and request a merge to M63 ASAP. Thank you.

#76: I'm requesting a merge again. Feel free to reject but I thought I'd provide some justification.

This bug has a larger impact than we previously discussed. It happens on opening a page for the first time in a new window and minimizing that window. For, ordinary browsing a flash of black is seen as the GPU process restarts, but for webgl we get the "webgl hit a snag" message. This bug can also be reproduced when casting a page (e.g. casting via hangouts using the cast button in chrome menu) and resizing the window.

#77: This bug is fixed for M63.

Thanks for more justification/details. Can you confirm if #66 has not been seen again? How safe is this fix overall? How does data from beta channel look?

I updated to 62.0.3202.89, but the error is still present.

My GPU log in updated browser:

Log Messages
GpuProcessHostUIShim: The GPU process exited normally. Everything is okay.
[5528:6832:1107/124334.987:ERROR:gles2_cmd_decoder.cc(8945)] : [.DisplayCompositor-0000020ACE1FE5F0]GL ERROR :GL_INVALID_OPERATION : glSetDrawRectangleCHROMIUM: failed on surface
[5528:6832:1107/124334.987:ERROR:gles2_cmd_decoder.cc(8946)] : Context lost because SetDrawRectangleCHROMIUM failed.
[5528:6832:1107/124334.987:ERROR:gles2_cmd_decoder.cc(5414)] : Error: 5 for Command kSetDrawRectangleCHROMIUM
[5528:6832:1107/124334.987:ERROR:gpu_channel_manager.cc(197)] : Exiting GPU process because some drivers cannot recover from problems.
GpuProcessHostUIShim: The GPU process exited normally. Everything is okay.
[6808:6864:1107/124336.875:ERROR:gles2_cmd_decoder.cc(8945)] : [.DisplayCompositor-0000020ADB7C2D60]GL ERROR :GL_INVALID_OPERATION : glSetDrawRectangleCHROMIUM: failed on surface
[6808:6864:1107/124336.875:ERROR:gles2_cmd_decoder.cc(8946)] : Context lost because SetDrawRectangleCHROMIUM failed.
[6808:6864:1107/124336.875:ERROR:gles2_cmd_decoder.cc(5414)] : Error: 5 for Command kSetDrawRectangleCHROMIUM
[6808:6864:1107/124336.875:ERROR:gpu_channel_manager.cc(197)] : Exiting GPU process because some drivers cannot recover from problems.
GpuProcessHostUIShim: The GPU process exited normally. Everything is okay.
[7828:3284:1107/124338.159:ERROR:gles2_cmd_decoder.cc(8945)] : [.DisplayCompositor-0000020AD5968AA0]GL ERROR :GL_INVALID_OPERATION : glSetDrawRectangleCHROMIUM: failed on surface
[7828:3284:1107/124338.159:ERROR:gles2_cmd_decoder.cc(8946)] : Context lost because SetDrawRectangleCHROMIUM failed.
[7828:3284:1107/124338.159:ERROR:gles2_cmd_decoder.cc(5414)] : Error: 5 for Command kSetDrawRectangleCHROMIUM
[7828:3284:1107/124338.159:ERROR:gpu_channel_manager.cc(197)] : Exiting GPU process because some drivers cannot recover from problems.
GpuProcessHostUIShim: The GPU process exited normally. Everything is okay.
GpuProcessHostUIShim: The GPU process exited normally. Everything is okay.


I'm listening a youtube music, and load an other page on other tab, example:
http://naplanya.boon.hu/

Minimalize window, maximalize window, and GPU process crash.

Deleted: gpu - Intel HD 530.html 108 KB

gpu - Intel HD 530.html 108 KB View Download

#82: the bug hasn't been fixed on M62

 Issue 782248  has been merged into this issue.

Google map crashes when minimizing/maximizing the window of Chrome.
(See  issue 782248 )

#79:

The fix should be very safe. We don't have data of the impact because we don't generate crash reports when we tear down the gpu process for context loss. Re: #66, there have been reports of problems with Fall Creators Update (issue 775898)  but those seem to be unrelated to the fix (they affect stable versions which don't have the fix).

Confirmed with sunnyps@ - this has baked in canary for over 2 weeks and in Beta for a week. As confirmed with #86, this should be a very safe merge. This seems to be causing a spike in Feedback as well. 

Approving merge to M62: branch:3202. 

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

commit 6c8832c6e3861b4070f864d923c2880e4d65d7c8
Author: Sunny Sachanandani <sunnyps@chromium.org>
Date: Wed Nov 08 22:57:09 2017

[merge to m62] viz: Do not use root render pass size in lieu of output surface size.

On Windows with Direct Composition enabled, we want to set the root
damage rect to the output surface (display) size after a resize, but use
the root render pass output rect instead. The output surface size may
differ from root render pass output size because rendering is
asynchronous with respect to resize.

Futhermore, we disable swaps in between the WindowPosChanging and
WindowPosChanged messages (DisableSwapUntilResize) by setting display
size to zero. We normally skip drawing in flight compositor frames
because the display and surface sizes don't match. However, if copy
output requests are present we try to draw and fail in SetDrawRectangle
because the damage is calculated from root render pass output rect which
is larger than display size of zero.

This manifested in a GPU process crash on minimizing the window in the
presence of a copy output request from the thumbnail helper.

R=piman,danakj
BUG= 773199 
TEST=GLRendererPartialSwapTest.SetDrawRectangle*

(cherry picked from commit 6015a99b8843d7eceea6868d7a83166007e8bf89)

Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel
Change-Id: I5a037de38866a64bcd83a04a9b9dca9e682a2454
Reviewed-on: https://chromium-review.googlesource.com/734170
Commit-Queue: Sunny Sachanandani <sunnyps@chromium.org>
Reviewed-by: Antoine Labour <piman@chromium.org>
Reviewed-by: danakj <danakj@chromium.org>
Reviewed-by: ccameron (ping after 24hr) <ccameron@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#511328}
Reviewed-on: https://chromium-review.googlesource.com/758501
Reviewed-by: Sunny Sachanandani <sunnyps@chromium.org>
Cr-Commit-Position: refs/branch-heads/3202@{#786}
Cr-Branched-From: fa6a5d87adff761bc16afc5498c3f5944c1daa68-refs/heads/master@{#499098}
[modify] https://crrev.com/6c8832c6e3861b4070f864d923c2880e4d65d7c8/cc/output/direct_renderer.cc
[modify] https://crrev.com/6c8832c6e3861b4070f864d923c2880e4d65d7c8/cc/output/overlay_unittest.cc
[modify] https://crrev.com/6c8832c6e3861b4070f864d923c2880e4d65d7c8/components/viz/service/display/gl_renderer_unittest.cc

For folks trying to verify the fix, the easiest repro is this:
1. Start chrome on Windows 10 with a new profile --user-data-dir=C:\tmp\...
2. Open github.com and maximize the window.
3. Minimize and then restore the window.

Without the fix, you should see a flash of black when restoring the window and errors in chrome://gpu about SetDrawRectangleCHROMIUM failing.

Rechecked this issue on Windows 10 using chrome beta version 63.0.3239.40 and observed that no error is displayed related to "SetDrawRectangleCHROMIUM". Tried the same on Stable build# 62.0.3202.89 and was able to reproduce it. Screen shots attached for the both the builds.

Adding TE-Verified labels for M63.

Thanks.!

Deleted: No Error Beta.png 137 KB

	No Error Beta.png 137 KB View Download

Deleted: Stable with Error.png 195 KB

	Stable with Error.png 195 KB View Download

 Issue 783769  has been merged into this issue.

I have verified this issue has been fixed in the latest Chrome 62 release (62.0.3202.94).
Thanks for all your efforts!

 Issue 763123  has been merged into this issue.