Can you provide a screenshot? And information from chrome://gpu

I can try to snag a screen shot next time it happens but the Chrome window literally becomes an entire black screen. I can grab chrome://gpu next time it happens for a few seconds but cannot get it when it stays black because Chrome is not usable at all at that point.

Thank you for providing more feedback. Adding the requester to the cc list.

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

We typically see sets of black squares for GPU memory and tiling issues. I wondered if that was what you were seeing (hence the screenshot). Providing the gpu info even just now can give us some idea of the GPU you are running.

It was not sets of black squares. The entire application window turns black. Can't see anything at all but solid black. Other apps on computer continue to work without issue but as soon as chrome is clicked to bring back in focus, its black.

I will get the GPU info now

GPU info attached

Deleted: Chrome GPU.txt 52.2 KB

Chrome GPU.txt 52.2 KB View Download

Zmo@, can you help find an owner for this issue - may be Windows specific. Don't see any red flag experiments (oop-d/oop-r) in GPU info. 

FYI there are a few similar reports in the Google Chrome Product Forums so I am not the only one experiencing

Please let me know if I can provide any additional logs or run anything outside of chrome to help pinpoint when the error occurs.

geofflang@, jmadill@: although may not related to the blackness, but this error message looks suspicious:

[1244:10836:1212/134545.434:ERROR:gl_surface_egl.cc(537)] : EGL Driver message (Error) eglMakeCurrent: Bad access.

I don't know the ANGLE's EGL implementation so could you help shedding some light here. What could be the possible reason MakeCurrent failed?

This is an Optimus dual GPU system (although about:gpu says it's not).

My suspicion of the black window is due to Chrome falling back to SwiftShader and somehow get stuck in a bad state for a bit (or for a long time).

josh@: can you turn on logging: https://www.chromium.org/for-testers/enable-logging

and when the black window happens again, shut down Chrome and send us the log file from your system. (if you don't want to share it publicly here, please send it to zmo@chromium.org)

There is still a possibility Chrome ran out of certain types of VRAM. Since it's Optimus, when running with NVidia, NVidia's VRAM is per resource type, so say your total VRAM may still be available, but the system may running out texture VRAM, things like that. Hopefully if that's the case, we will be able to see an OUT_OF_MEMORY error in the log, if you don't mind sharing.

Looking at the code, eglMakeCurrent can only fail with a BAD_ACCESS error when the low-level D3D11 internals fail (either creating a resource or applying the context's state).  This looks like an edge case in our conversion of internal errors to EGL errors where the message gets dropped, going to add some extra logging and it may point us to what error is being generated.

geofflang@: thanks. Assign this to you to enhance error handling. Then feel free to assign it back to me.

The following revision refers to this bug:
  https://chromium.googlesource.com/angle/angle/+/7139b434210c8c168aece65022ee9196c2bf550b

commit 7139b434210c8c168aece65022ee9196c2bf550b
Author: Geoff Lang <geofflang@chromium.org>
Date: Sat Dec 15 16:39:47 2018

Print a warning on unexpected internal errors.

The error message can be dropped when converting angle::Result to egl::Error.
This makes sure something is always printed when we get an unexpected error.

BUG=914911

Change-Id: Icc8b06b1c13e3ea83287da5a217f4c8bc218deec
Reviewed-on: https://chromium-review.googlesource.com/c/1378689
Reviewed-by: Jamie Madill <jmadill@chromium.org>
Commit-Queue: Geoff Lang <geofflang@chromium.org>

[modify] https://crrev.com/7139b434210c8c168aece65022ee9196c2bf550b/src/libANGLE/Context.cpp

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

commit 13d96421161d20393a537b804904f65ed4d86c3f
Author: chromium-autoroll <chromium-autoroll@skia-public.iam.gserviceaccount.com>
Date: Sat Dec 15 18:05:57 2018

Roll src/third_party/angle f307584255da..7139b434210c (1 commits)

https://chromium.googlesource.com/angle/angle.git/+log/f307584255da..7139b434210c


git log f307584255da..7139b434210c --date=short --no-merges --format='%ad %ae %s'
2018-12-15 geofflang@chromium.org Print a warning on unexpected internal errors.


Created with:
  gclient setdep -r src/third_party/angle@7139b434210c

The AutoRoll server is located here: https://autoroll.skia.org/r/angle-chromium-autoroll

Documentation for the AutoRoller is here:
https://skia.googlesource.com/buildbot/+/master/autoroll/README.md

If the roll is causing failures, please contact the current sheriff, who should
be CC'd on the roll, and stop the roller if necessary.

CQ_INCLUDE_TRYBOTS=luci.chromium.try:android_optional_gpu_tests_rel;luci.chromium.try:linux_optional_gpu_tests_rel;luci.chromium.try:mac_optional_gpu_tests_rel;luci.chromium.try:win_optional_gpu_tests_rel

BUG=chromium:914911
TBR=ynovikov@chromium.org

Change-Id: Idc2893e4d44b9806592fad7c1b8a203905ec4b5f
Reviewed-on: https://chromium-review.googlesource.com/c/1379388
Reviewed-by: chromium-autoroll <chromium-autoroll@skia-public.iam.gserviceaccount.com>
Commit-Queue: chromium-autoroll <chromium-autoroll@skia-public.iam.gserviceaccount.com>
Cr-Commit-Position: refs/heads/master@{#616987}
[modify] https://crrev.com/13d96421161d20393a537b804904f65ed4d86c3f/DEPS

josh: I added more logging that should show up in Chrome version 73.0.3642.0.  If you use Chrome canary and upload about:gpu for us again, hopefully it will have more information to diagnose this.

zmo: I'm about to go on vacation for the holidays, going to send this back to you until I'm back.

Ok I will await the update to come through and report back

Interesting enough, I updated from Windows 1803 to 1809 as well as updated my computer's drivers and now what used to be black screens seem to be presenting as complete freeze ups of chrome. I check Task Manager each time and 80% of CPU and 60% of RAM is available... Just surfing various websites, not using one in particular. All extensions disabled.

Ok I got 73.0.3642.0 and will run to see what happens

Have a great vacation and Holiday!

Freeze ups continue and now instead of black screens I am seeing completely white screens. Only Chrome is freezing. Still at least 50% RAM and 50% available at all times this is occurring. I dont even have many tabs open compared to what I usually do. Log attached from right after the last freeze up/white screen. Will upload another if it happens again.

Deleted: Chrome GPU2.txt 141 KB

Chrome GPU2.txt 141 KB View Download

+tdresser@: see the #18 attachment. What does this mean?

[13496:13288:1218/132719.808:ERROR:latency_info.cc(145)] : Surface::TakeLatencyInfoFromFrame, LatencyInfo vector size 102 is too big.

Out of curiosity, is there a way to see what tab is taking up memory, either in real-time or in a log? I have one dozen tabs open (usually several dozen) and Canary is currently eating 8-9 GB of RAM for only one dozen tabs. I have never seen stable Chrome use so much. Is that normal for Canary? Thanks

You can open menu->More Tools->Task Manager

Right click on the first row to add more columns to watch

Completely black screens are happening again

I took another log for your review (attached)

Looking at my computer's task manager, plenty of RAM, CPU, GPU left. Chrome was only using a few GB out of the 16 GB of RAM.

Deleted: Chrome GPU3.txt 143 KB

Chrome GPU3.txt 143 KB View Download

So very interesting thing happening now. Whenever I go to open a new tab, drag it to its own window (separate from other tabs), Chrome goes black and stays black. I can press ctrl-w and it closes the tab and I can go back to using chrome again but if I try to open a new tab and drag to a new window, the same thing happens. Attached is a screenshot.

Deleted: chrome black screen.png 16.7 KB

	chrome black screen.png 16.7 KB View Download

And another screenshot

And another screenshot

Deleted: chrome black screen2.png 321 KB

	chrome black screen2.png 321 KB View Download

+sadrul, see #19.

error message from #22 is interesting. There are a lot of "glSetDrawRectangleCHROMIUM: failed on surface"

Unfortunately the reason SetDrawRectangle failed on the surface is a DLOG. Let me fix that and then you can run Canary with the fix so we could understand what's going on there.

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

commit bccf0827db6115a8fac5b0ab7ad2babe5d1d597a
Author: Zhenyao Mo <zmo@chromium.org>
Date: Sat Jan 05 03:00:23 2019

Add VLOG to DirectCompositionChildSurfaceWin::SetDrawRectangle

This is for investigation purpose and will revert after this gets
in Canary and we get the error message from user.

BUG=914911
TEST=bots
R=piman@chromium.org

Change-Id: I67761a335c7e6dee36a2beb8c593f03c4b2d1958
Reviewed-on: https://chromium-review.googlesource.com/c/1396847
Reviewed-by: Antoine Labour <piman@chromium.org>
Commit-Queue: Zhenyao Mo <zmo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#620164}
[modify] https://crrev.com/bccf0827db6115a8fac5b0ab7ad2babe5d1d597a/gpu/ipc/service/direct_composition_child_surface_win.cc

josh: can you run again on the latest Canary (check about:version, make sure it's 73.0.3664.1 or newer). When you are able to reproduce the issue, provide the about:gpu data again. Hopefully it will get the error messages I just baked into Canary build.

ok i updated and will report back with data when it happens again, thanks

So interestingly enough, Chrome seems much more stable all of the sudden. I will continue using but I was generally getting the black screens and freezing several times a day. It has not happened in almost an entire week. I have been updating Chrome Canary daily. Was there a code change? I also happen to run a Windows update (latest monthly cumulative for Win 10 1809) last week around the same time so unclear if that may have played a role.