mikegoodrickcontest@ Thanks for the issue.

Tested this issue on Mac OS 10.12.6 and Windows 10 using the latest Stable 63.0.3239.108 and Canary 65.0.3299.0 and unable to reproduce the issue by following the below steps.

1. Launched chrome and navigated to Chrome://version, chrome://extensions, Chrome://settings, www.google.com and cannot observe any blank pages on Chrome.
All the webpages are rendering correctly and no issues are seen.

Attached is the screen cast for reference.

Please can you update chrome to the latest Stable, retry the issue and update the thread with the observations.

Thanks...

Deleted: 795649.webm 3.6 MB

	795649.webm 3.6 MB View Download

Yes. This is the latest version of chrome. 63.0.3239.108

I’m still unable to access any page via the chrome browser. Even the new tab screen where it normally shows my most visited pages is blank. Any ideas on troubleshooting this. I can’t access chrome://settings to change anything. Is there another way to access the settings page?

Thank you for providing more feedback. Adding requester "sc00335628@techmahindra.com" to the cc list and removing "Needs-Feedback" label.

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

Unable to reproduce the issue on Win-10 and mac 10.12.6 using chrome reported version #63.0.3239.108 and latest canary #65.0.3299.0.
Observed that pages i.e chrome://settings, yahoo.com, nytimes.com e.t.c rendered without any issues. No blank page is seen.

Could someone from Blink>Paint team please have a look into the issue.

Thanks...!!

I am also seeing this issue. I'm on a MacBook Pro (Retina, 15-inch, Mid 2015) with OS version 10.12.6. It seems like the elements of the page are being positioned correctly but not being shown. As I hover my mouse around the blank page the cursor changes when I'm over a link and when I click I navigate to that link. Also this is reproducing on Stable (63.0.3239.108), Beta (64.0.3282.39), and Canary (65.0.3300.00). I'm moving this to P0 since this bug makes Chrome completely unusable.

I can't reproduce this yet but am debugging with amaralp@.

Attached are the contents of about:gpu. These were from running Canary (65.0.3300.00) with no flags.

Deleted: gpu.htm 1.2 MB

gpu.htm 1.2 MB View Download

I found a person next to me who has the exact same model of computer with
the exact same OS version. Does not reproduce for them.

@bug reporter: please restart your computer, that may fix the issue.
I think it is related to a broken GPU state.

Yes @amaralp this is exactly what is happening. I've restarted my computer, reset PRAM. Even reinstalled the OS. Nothing is working.

I had this problem as well, and the GPU suspicion seems correct because I am able to work around this problem by launching Chrome from the command line with --disable-gpu.

Happy to post chrome:gpu output as well, provided Chrome will render it with --disable-gpu omitted. (I have not yet restarted as mikegood noted, but will do so shortly and report back).

The problem for me occurred mid-session. I left for the holidays, and when I came back, rendered windows were still rendered, but new tabs would no longer render. I installed the latest version, that didn't fix it. Incognito, etc. would not fix it.

By launching chrome from the command line, I figured it might have something to do with GPU since the console showed errors like: 

[88903:775:1227/115849.611744:ERROR:gles2_cmd_decoder.cc(4496)] [.DisplayCompositor-0x7fd05c48d800]GL ERROR :GL_INVALID_FRAMEBUFFER_OPERATION : glDrawElements: framebuffer incomplete
[88903:775:1227/115849.611846:ERROR:gles2_cmd_decoder.cc(4496)] [.DisplayCompositor-0x7fd05c48d800]GL ERROR :GL_INVALID_FRAMEBUFFER_OPERATION : glDrawElements: framebuffer incomplete
[88903:775:1227/115849.615067:ERROR:gles2_cmd_decoder.cc(4496)] [.DisplayCompositor-0x7fd05c48d800]GL ERROR :GL_INVALID_FRAMEBUFFER_OPERATION : glDrawElements: framebuffer incomplete
[88903:775:1227/115849.615139:ERROR:gles2_cmd_decoder.cc(4496)] [.DisplayCompositor-0x7fd05c48d800]GL ERROR :GL_INVALID_FRAMEBUFFER_OPERATION : glDrawElements: framebuffer incomplete
[88903:775:1227/115849.615166:ERROR:gles2_cmd_decoder.cc(12104)] [.DisplayCompositor-0x7fd05c48d800]GL ERROR :GL_INVALID_VALUE : glScheduleOverlayPlaneCHROMIUM: unknown texture
[88903:775:1227/115849.629687:ERROR:gles2_cmd_decoder.cc(4496)] [.DisplayCompositor-0x7fd05c48d800]GL ERROR :GL_INVALID_FRAMEBUFFER_OPERATION : glDrawElements: framebuffer incomplete
[88903:775:1227/115849.629770:ERROR:gles2_cmd_decoder.cc(4496)] [.DisplayCompositor-0x7fd05c48d800]GL ERROR :GL_INVALID_FRAMEBUFFER_OPERATION : glDrawElements: framebuffer incomplete
[88903:775:1227/115849.629809:ERROR:gles2_cmd_decoder.cc(4496)] [.DisplayCompositor-0x7fd05c48d800]GL ERROR :GL_INVALID_FRAMEBUFFER_OPERATION : glDrawElements: framebuffer incomplete
[88903:775:1227/115849.629930:ERROR:gles2_cmd_decoder.cc(4496)] [.DisplayCompositor-0x7fd05c48d800]GL ERROR :GL_INVALID_FRAMEBUFFER_OPERATION : glDrawElements: framebuffer incomplete
[88903:775:1227/115849.629967:ERROR:gles2_cmd_decoder.cc(12104)] [.DisplayCompositor-0x7fd05c48d800]GL ERROR :GL_INVALID_VALUE : glScheduleOverlayPlaneCHROMIUM: unknown texture

Restarting seemed to fix it for me, thanks @chrishtr!

When I relaunched Chrome from the command line (to see console output) but *without* the --disable-gpu, the previous errors were replaced with the following:

[1602:775:1227/123809.165067:ERROR:web_input_event_builders_mac.mm(555)] Not implemented reached in static blink::WebGestureEvent content::WebGestureEventBuilder::Build(NSEvent *, NSView *)

However, the pages now rendered.

So I quit Chrome again, and relaunched from the "icon" (i.e. as a "normal" user) and confirmed the restart changed the behavior from not displaying to actually displaying. I should have tried to load chrome://gpu before restart but didn't think of it. (My guess is that it would have also loaded blank, but Command-Option-U, Command-A, Command C could have copied the page source).

Will do that if it reoccurs and post here.

Same problem here. Restarting the macbook fixed the issue. Attaching chrome:gpu content.

Deleted: gpu.htm 587 KB

gpu.htm 587 KB View Download

I also had this issue. Restarting the OS fixed the problem. '--disable-gpu' (before restarting) also worked. 

Anyway, attached is 'gpu.htm' saved when I had this issue (every page is blank). 

khan@:  View-Source and select All + Copy All does not work. When you come across this problem again, you have to use File - Save Page As (or Command-S) after going to chrome://gpu. 

Deleted: gpu.htm 369 KB

gpu.htm 369 KB View Download

about:gpu from #9 shows these logs:

[77998:775:1221/155627.674499:ERROR:gl_image_io_surface.mm(293)] : Error in CGLTexImageIOSurface2D: invalid numerical value
[77998:775:1221/155627.674611:ERROR:gles2_cmd_decoder.cc(18096)] : [.RenderWorker-0x7fe8b7826600.GpuRasterization]GL ERROR :GL_INVALID_OPERATION : glTexStorage2DImageCHROMIUM: Failed to create or bind GL Image
[77998:775:1221/155627.674660:ERROR:gles2_cmd_decoder.cc(12575)] : [.RenderWorker-0x7fe8b7826600.GpuRasterization]GL ERROR :GL_INVALID_VALUE : glSetColorSpaceMetadataCHROMIUM: no image associated with texture


It sounds like we're doing bad things?

Issue 795858 has been merged into this issue.

To summarize so far
- all are 10.12.6
- all have Intel GPUs (though various models)
- this resolves only by reboot (except for one user who is permanently broken)
- this ranges from Chrome 63 through Chrome 65.

The reports from #16 and #17 don't have the CGLTexImageIOSurface2D call, but have tons of other invalid framebuffer operation spew.

This feels to me like an OS bug -- the GL driver getting into some sort of persistent bad state -- I don't think anything else can explain persistence across Chrome restarts.

Is there anyone in MTV or SFO who can reproduce this semi-reliably?

Also, any users affected by this: If you kill the Chrome GPU Process (in Chrome's task manager) 3 times, it will take you to software mode, which should still display.

The issue has not occurred again, if it does will report back. 

Context i had reported the issue on https://bugs.chromium.org/p/chromium/issues/detail?id=795858&desc=2
Which has been merged with this. 

 Issue 801483  has been merged into this issue.

vmiura is currently seeing this issue.

When running with --disable-gpu, we get the error:
  In AcceleratedWidgetMac::UpdateCALayerTree
  IOSurfaceLookupFromMachPort fails
  with the DLOG "Unable to open IOSurface for frame."

When running without --disable-gpu, we get the DCHECK:
  In GpuMemoryBufferFactoryIOSurface::CreateAnonymousImage
  IOSurfaceLookupFromMachPort fails
  and we DCHECK immediately thereafter
  I suspect that in non-DCHECK builds, this becomes
  "Error in CGLTexImageIOSurface2D: invalid numerical value
  because we pass nullptr to CGLTexImageIOSurface2D

+rsesek for mach wizardry.

The sequence of events we see is as follows, **all in the same process**. We see this in two forms -- one in the browser and one in the GPU process.

1. We call IOSurface.
   It succeeds (if it failed we would have spewed an error)
2. We call IOSurfaceCreateMachPort
   We **DO NOT** check if this succeeds -- it has no error code, it just returns a port
3. We call IOSurfaceLookupFromMachPort
   This FAILS

vmiura@ is currently testing a local build to see if IOSurfaceCreateMachPort is returning an invalid handle

Patch to test is:

diff --git a/components/viz/service/display_embedder/software_output_device_mac.cc b/components/viz/service/display_embedder/software_output_device_mac.cc
index b256bf2d60f7..39f5a7a79815 100644
--- a/components/viz/service/display_embedder/software_output_device_mac.cc
+++ b/components/viz/service/display_embedder/software_output_device_mac.cc
@@ -185,6 +185,7 @@ void SoftwareOutputDeviceMac::EndPaint() {
     ca_layer_params.pixel_size = pixel_size_;
     ca_layer_params.io_surface_mach_port.reset(
         IOSurfaceCreateMachPort(current_paint_buffer_->io_surface));
+    DCHECK(ca_layer_params.io_surface_mach_port);
     ui::CALayerFrameSink* ca_layer_frame_sink =
         ui::CALayerFrameSink::FromAcceleratedWidget(widget_);
     if (ca_layer_frame_sink) {
diff --git a/gpu/ipc/client/gpu_memory_buffer_impl_io_surface.cc b/gpu/ipc/client/gpu_memory_buffer_impl_io_surface.cc
index 40e592b900b8..956f83d5d969 100644
--- a/gpu/ipc/client/gpu_memory_buffer_impl_io_surface.cc
+++ b/gpu/ipc/client/gpu_memory_buffer_impl_io_surface.cc
@@ -85,6 +85,7 @@ base::Closure GpuMemoryBufferImplIOSurface::AllocateForTesting(
   handle->type = gfx::IO_SURFACE_BUFFER;
   handle->id = kBufferId;
   handle->mach_port.reset(IOSurfaceCreateMachPort(io_surface));
+  DCHECK(handle->mach_port);
   return base::Bind(&NoOp);
 }
 
diff --git a/gpu/ipc/service/gpu_memory_buffer_factory_io_surface.cc b/gpu/ipc/service/gpu_memory_buffer_factory_io_surface.cc
index f502262d4c13..3b36619458a3 100644
--- a/gpu/ipc/service/gpu_memory_buffer_factory_io_surface.cc
+++ b/gpu/ipc/service/gpu_memory_buffer_factory_io_surface.cc
@@ -54,6 +54,7 @@ GpuMemoryBufferFactoryIOSurface::CreateGpuMemoryBuffer(
   handle.type = gfx::IO_SURFACE_BUFFER;
   handle.id = id;
   handle.mach_port.reset(IOSurfaceCreateMachPort(io_surface));
+  DCHECK(handle.mach_port);
   return handle;
 }
 
diff --git a/gpu/ipc/service/image_transport_surface_overlay_mac.mm b/gpu/ipc/service/image_transport_surface_overlay_mac.mm
index 8cad9b07e041..8281cdaeb187 100644
--- a/gpu/ipc/service/image_transport_surface_overlay_mac.mm
+++ b/gpu/ipc/service/image_transport_surface_overlay_mac.mm
@@ -228,6 +228,7 @@ void IOSurfaceContextNoOp(scoped_refptr<ui::IOSurfaceContext>) {
       if (io_surface) {
         params.ca_layer_params.io_surface_mach_port.reset(
             IOSurfaceCreateMachPort(io_surface));
+        DCHECK(params.ca_layer_params.io_surface_mach_port);
       }
     }
     params.ca_layer_params.pixel_size = pixel_size_;

Update to #27. The sequence is

1. We call IOSurfaceCreate.
   It succeeds (if it failed we would have spewed an error)
2. We call IOSurfaceCreateMachPort
   This returns a non-null mach port
3. We call IOSurfaceLookupFromMachPort
   This FAILS -- it returns nullptr

This is a "should never possibly ever fail" sequence of calls. Failing 1 is okay, but failing 2 and 3 should never happen.

I'll add CHECKs to see how often "should never possibly ever happen" ends up happening in practice. The next question will be "why is this happening".

Of note is that we can avoid this sequence of calls in 	GpuMemoryBufferFactoryIOSurface::CreateAnonymousImage.

I see these reports as far back as Chrome 63, and we only started using anonymous images heavily in r512615, which is Chrome 64 (sunnyps please verify).

#31 Yeah, that's the right commit and it landed in 64.0.3254.0.

Does this only happen if IOSurfaceLookupFromMachPort is called in another process? Does testing with --single-process or --in-process-gpu help?

This patch skips the mach-port-roundtrip:

diff --git a/gpu/ipc/service/gpu_memory_buffer_factory_io_surface.cc b/gpu/ipc/service/gpu_memory_buffer_factory_io_surface.cc
index f502262d4c13..82a9e7a935cc 100644
--- a/gpu/ipc/service/gpu_memory_buffer_factory_io_surface.cc
+++ b/gpu/ipc/service/gpu_memory_buffer_factory_io_surface.cc
@@ -54,6 +54,7 @@ GpuMemoryBufferFactoryIOSurface::CreateGpuMemoryBuffer(
   handle.type = gfx::IO_SURFACE_BUFFER;
   handle.id = id;
   handle.mach_port.reset(IOSurfaceCreateMachPort(io_surface));
+  DCHECK(handle.mach_port);
   return handle;
 }
 
@@ -109,17 +110,17 @@ GpuMemoryBufferFactoryIOSurface::CreateAnonymousImage(const gfx::Size& size,
                                                       bool* is_cleared) {
   // Note that the child id doesn't matter since the texture will never be
   // directly exposed to other processes, only via a mailbox.
-  gfx::GpuMemoryBufferHandle handle = CreateGpuMemoryBuffer(
-      gfx::GpuMemoryBufferId(next_anonymous_image_id_++), size, format, usage,
-      kAnonymousClientId, gpu::kNullSurfaceHandle);
-
-  base::ScopedCFTypeRef<IOSurfaceRef> io_surface;
-  io_surface.reset(IOSurfaceLookupFromMachPort(handle.mach_port.get()));
-  DCHECK_NE(nullptr, io_surface.get());
+  base::ScopedCFTypeRef<IOSurfaceRef> io_surface(
+      gfx::CreateIOSurface(size, format, false));
+  if (!io_surface) {
+    DLOG(ERROR) << "Failed to allocate IOSurface for CreateAnonymousImage.";
+    return scoped_refptr<gl::GLImage>();
+  }
 
+  gfx::GpuMemoryBufferId buffer_id(next_anonymous_image_id_++);
   scoped_refptr<gl::GLImageIOSurface> image(
       gl::GLImageIOSurface::Create(size, internalformat));
-  if (!image->Initialize(io_surface.get(), handle.id, format)) {
+  if (!image->Initialize(io_surface.get(), buffer_id, format)) {
     DLOG(ERROR) << "Failed to initialize anonymous GLImage.";
     return scoped_refptr<gl::GLImage>();
   }

Related to issue 574014, where we saw that clients would fail to open service-provided mach ports. For that issue there exists a clusterfuzz repro.

The patch in #34 works with GPU rasterization enabled.  With --disable-gpu-raster, we are still failing -- but in the Renderer process.

I suspect getting the IOSurface from the mach port on the Renderer side is failing.

Thanks!

I have a patch to trigger crashes to give us some visibility into this on Canary. I'll be able to refine this from there.

I am starting to feel that we should create anonymous images and use glTexSubImage for one-copy -- it may even end up being more efficient than zero-copy.

The following patch landed against this bug, but I forgot to include the bug #

Add CHECKs to calls to IOSurfaceLookupFromMachPort

When allocating an anonymous IOSurface-backed GLImage, we have the
sequence of calls
- IOSurfaceCreate
- IOSurfaceCreateMachPort
- IOSurfaceRelease (implicitly in ScopedCFTypeRef<IOSurfaceRef>)
- IOSurfaceLookupFromMachPort
The final call persistently fails on some machines.

This adds a CHECK when that call fails, so we can assess how often
it occurs in the wild.

This also adds a call to IOSurfaceCreateMachPort and
IOSurfaceLookupFromMachPort before the implicit IOSurfaceRelease, to
see if this may be the result of a reference counting bug.

Add lots more LOG(ERROR) spew to help further diagnose this.

Cq-Include-Trybots: master.tryserver.chromium.android:android_optional_gpu_tests_rel;master.tryserver.chromium.linux:linux_optional_gpu_tests_rel;master.tryserver.chromium.mac:mac_optional_gpu_tests_rel;master.tryserver.chromium.win:win_optional_gpu_tests_rel
Change-Id: Ie630067759d0bdf096be907986e53afdc632b15d

I've attached a stand-alone app which does

- IOSurfaceCreate (to create surface A)
- IOSurfaceCreateMachPort (on surface A)
- IOSurfaceLookupFromMachPort (to create surface B)

and the call to IOSurfaceLookupFromMachPort has failed on vmiura's machine.

This indicates that something really terrible is going on on the machine -- that sequence of calls should not fail. I'll file a radar and follow up with Apple.

What macOS version was that on? It may be helpful is to run your test program with `sudo dtruss -a /test/program` to get return values from all system calls. That could shed light on any potential port creation error code.

These were all reported on 10.12.6

But ... the crash reports are rolling in for the added CHECKs, and there are lots of reports of IOSurfaceCreate,IOSurfaceCreateMachPort,IOSurfaceLookupFromMachPort failing. They're coming in from 10.11 an 10.12 so far, but we have very few numbers coming in now -- more to follow.

I'll revert the CHECK soon, cause it's big enough to impact stability.

Users experienced this crash on the following builds:

Mac Canary 66.0.3336.0 -  2.03 CPM, 6 reports, 6 clients (signature gpu::GpuMemoryBufferFactoryIOSurface::CreateGpuMemoryBuffer)

If this update was incorrect, please add "Fracas-Wrong" label to prevent future updates.

- Go/Fracas

Gentle ping.  What was the next action to take after #42?

I have left the DumpWithoutCrashings in place [0]. In 70.0.3538.77, which was Stable for ~30 days, has zero instances of this DumpWithoutCrashing.

So this seems to have gone away. I'll WontFix. If we start DWCing, the chrome crash triage will file a new bug.

[0] https://cs.chromium.org/chromium/src/gpu/ipc/service/gpu_memory_buffer_factory_io_surface.cc?rcl=2bd4fd8e90cf59edf3b6883ca8cbb55d7e0e8289&l=72