I'm fine with using a fresh profile if that helps but I need my extensions from Canary; is there any way to migrate that now that my profile is broken?

Just encountered this as well with 52.0.2708.0 (Official Build) canary (64-bit).

Unfortunately the pixel tests on Retina MBPs were disabled yesterday due to  Issue 550016 , but given that these tests all run with a fresh profile, they probably wouldn't have caught it.

Forcibly crashing the GPU process 3 times causes things to render again.

 Issue 603557  has been merged into this issue.

Re #2: I confirm, killing the GPU process a few times until it stops restarting & then refreshing the tab makes the tab to appear.

For reference, I'm on the latest 15" Retina MacBook Pro, the discrete graphics card is active.

FYI, as a temporary workaround I got it to work by disabling gpu process, after passing "--disable-gpu" flag on command line. 

Here are some GPU-related changes that the authors should investigate as the cause:

amistry@
Use a token to initialise ChannelMojo and MojoApplication everywhere.
Review URL: https://codereview.chromium.org/1880343002

fsamuel@
Move LatencyInfo to ui/latency_info
Review URL: https://codereview.chromium.org/1871233002

ccameron@ (although you probably know for sure that they we'ren't needed)
GLContext: Remove WasDirtiedExternally methods
Review URL: https://codereview.chromium.org/1880923002

calecurtis@ (although this is probably just movie playback)
Disable idle suspend for GpuVideoDecoder produced frames on OSX, Win.
Review URL: https://codereview.chromium.org/1879253002

Mine is only related to idle media playback, so if there's no media on the page the code is never invoked.

My patch is only a mechanical refactor... I don't think it's the cause.

Double-checking https://codereview.chromium.org/1880923002, this continues to look like dead-code to me. Feel free to speculatively revert.

There were some profile-related issues not too long ago ... have those been investigated and resolved?

What kind of profile? Not user profile?

IIRC it was issue 582840

I did a pull yesterday at 10:55am and didn't see a problem when I built, so we're probably looking for a change that landed after about 6:00PM UTC.

I'm suspecting a GPU-related issue because of notes #5 and #7.

I discovered that the bug is only occurring on my MacBook Pro, not my desktop machine.

A user on IRC reports that this bug happens on their macbook with HD5300 graphics, but not on their macbook with 4000 graphics.

I'm seeing this locally as well.

It reproduces with and without the CoreAnimation renderer. It appears that we aren't even sending a frame to the browser to display.

Of note is that the views-based task manager appears correctly, so the browser compositor is behaving correctly, but something is messed up in getting the frame from the renderer compositor.

Oh, this is more serious than I thought. The renderer process just dies immediately upon startup.

Somehow having GPU process disabled allowed the renderer process to not die.

I have pulled and built on my laptop and can't reproduce. I have gclient sync --revision'ed back to the last cl in the delta and still can't reproduce it. I was hoping to find the offending cl by reverting patches on my repo. Given that this isn't an option I am looking at reverting patches directly. And given that I have not heard from amistry@, and his cl is suspected, my plan is to revert that one first.

I have reverted https://codereview.chromium.org/1891043002/. We'll need to see if tomorrow's Canary runs OK or not.

I'm taking a look and seeing if I can repro with my CL. My understand is that nothing in the GPU uses Mojo, so my change should have had no effect on IPCs to the GPU.

It looks like reverting the cl broke the tree, so you won't have to worry about relanding it. I'm working with the sheriff to get it back landed again.

Actually, since this is a mac bug, can someone try reverting https://codereview.chromium.org/1867733002 locally and see if that fixes it. I don't have access to a mac machine at the moment. The change first appears in 52.0.2708.0.

I can't reproduce the blank page problem locally. The best I can do at this point is revert in the tree, which I'm not against trying. But are you saying that you don't believe your change is responsible?

FWIW, my graphics card is AMD Radeon R9 M370X 2048 MB. If you revert something and put it in next Canary update, I'll report back if it's fixed for me or not.

I'm saying it shouldn't be since it's not specific to any platform, and others don't appear to be affected. But I honestly don't know. I'm stabbing in the dark.

And I just noticed your comment #14, so maybe ignore my last comment.

Actually, disregard that comment - I did a pull on my desktop machine, but I am not able to reproduce the problem there anyway (in a local build or the current Canary).

I will revert the POSIX shared memory cl and then we can see how the Canary does tomorrow.

I have reverted https://codereview.chromium.org/1867733002. Hopefully the revert will stick.

MacBook Pro 13" Retina (2015 Early), works like a charm with the latest Canary.

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

commit 1c9502415491e04f9199059f59b2e9e278b0e1cf
Author: amistry <amistry@chromium.org>
Date: Fri Apr 15 00:08:11 2016

Revert "Use a token to initialise ChannelMojo and MojoApplication everywhere."

This reverts commit babb3f34fe20effb72c81104b63b2974271ad88d.

BUG= 603452 
TBR=rockot@chromium.org

Review URL: https://codereview.chromium.org/1883053003

Cr-Commit-Position: refs/heads/master@{#387485}

[modify] https://crrev.com/1c9502415491e04f9199059f59b2e9e278b0e1cf/content/browser/gpu/gpu_process_host.cc
[modify] https://crrev.com/1c9502415491e04f9199059f59b2e9e278b0e1cf/content/browser/gpu/gpu_process_host.h
[modify] https://crrev.com/1c9502415491e04f9199059f59b2e9e278b0e1cf/content/browser/mojo/mojo_application_host.cc
[modify] https://crrev.com/1c9502415491e04f9199059f59b2e9e278b0e1cf/content/browser/mojo/mojo_application_host.h
[modify] https://crrev.com/1c9502415491e04f9199059f59b2e9e278b0e1cf/content/browser/renderer_host/render_process_host_impl.cc
[modify] https://crrev.com/1c9502415491e04f9199059f59b2e9e278b0e1cf/content/browser/utility_process_host_impl.cc
[modify] https://crrev.com/1c9502415491e04f9199059f59b2e9e278b0e1cf/content/child/child_thread_impl.cc
[modify] https://crrev.com/1c9502415491e04f9199059f59b2e9e278b0e1cf/content/child/child_thread_impl.h
[modify] https://crrev.com/1c9502415491e04f9199059f59b2e9e278b0e1cf/content/child/mojo/mojo_application.cc
[modify] https://crrev.com/1c9502415491e04f9199059f59b2e9e278b0e1cf/content/child/mojo/mojo_application.h
[modify] https://crrev.com/1c9502415491e04f9199059f59b2e9e278b0e1cf/content/common/content_message_generator.h
[modify] https://crrev.com/1c9502415491e04f9199059f59b2e9e278b0e1cf/content/common/in_process_child_thread_params.cc
[modify] https://crrev.com/1c9502415491e04f9199059f59b2e9e278b0e1cf/content/common/in_process_child_thread_params.h
[add] https://crrev.com/1c9502415491e04f9199059f59b2e9e278b0e1cf/content/common/mojo/channel_init.cc
[add] https://crrev.com/1c9502415491e04f9199059f59b2e9e278b0e1cf/content/common/mojo/channel_init.h
[add] https://crrev.com/1c9502415491e04f9199059f59b2e9e278b0e1cf/content/common/mojo/mojo_messages.h
[modify] https://crrev.com/1c9502415491e04f9199059f59b2e9e278b0e1cf/content/content_common.gypi
[modify] https://crrev.com/1c9502415491e04f9199059f59b2e9e278b0e1cf/content/renderer/render_thread_impl_browsertest.cc
[modify] https://crrev.com/1c9502415491e04f9199059f59b2e9e278b0e1cf/content/test/render_thread_impl_browser_test_ipc_helper.cc
[modify] https://crrev.com/1c9502415491e04f9199059f59b2e9e278b0e1cf/content/test/render_thread_impl_browser_test_ipc_helper.h
[modify] https://crrev.com/1c9502415491e04f9199059f59b2e9e278b0e1cf/ipc/ipc_message_start.h

I've done a little more digging and can reliably turn this bug on and off on certain chromium mac snapshots:
1. r387047 (before posix change) cannot repro
2. r387144 (after posix, but before Mojo) can repro

The magic flag to repro this is --enable-mojo-channel (a running experiment, which is why only some people are seeing this problem). It's still a Mojo problem, actually it's my problem, but not caused by my recent change.

After turning on --enable-mojo-channel, I see the following on the terminal:
ERROR:mach_port_relay.cc(35) Error receiving mach ports
ERROR:node_channel.cc(412) Error receiving mach ports
I'm guessing the renderer and GPU use mach shared memory to transfer textures and/or command buffers and that's where it's failing. I need to look into this further.

Theoretically, the POSIX change that was reverted was only removing dead code. Maybe it tickles the bug somehow?

Also, can we turn off the experiment on Mac for now?

I'll turn it off

It's possible there's something else in between 387047 and 387144 that causes it. Because ChannelMojo works in 387047 (presumably with mach ports, although I can't tell it's being used for certain without doing a build and adding logging).

Narrowed down the breakage to the range (387047, 387068].

mark: Why we wouldn't get crash reports for renderer crashes? 

I've been looking into what the root cause is. Turns out I'm an idiot and wrote a broken mach ports on Mojo implementation. I naively assumed that it's not valid to send a null mach port. But it turns out, some code does. So when you attempt to send a null mach port over Mojo, various things error (and a build with dchecks on will crash) and that error propagates. It likely closes the IPC channel which causes the renderer to be killed by the browser and hence no crash reports.

The solution is simple. Allow null ports to be sent over Mojo. I have this implemented locally, but it's Friday and I'm too lazy to write tests right now. Given Erik's change triggered this and was reverted (and the ChannelMojo experiment will be turned off), the next Canary build will work correctly and I can fix this for realz on Monday.

Ken: Re-assign this bug to me once you've disabled the experiment.

 Issue 603587  has been merged into this issue.

I confirm that Canary 52.0.2709.0 works correctly for me.

amistry@ - thank you for tracking down the root cause.

Has the experiment been disabled? I ask because I'm still getting blank pages in my default user-data-dir. I created two fresh data-dirs this morning. For one of them 52.0.2708.0 launched fine the first time but now gives me blank pages every time I try to use it, which implies it was enrolled in the experiment this morning. What's worse is that my Canary won't update/isn't updating with the blank pages, so presumably on one else in this situation is able to pull down 52.0.2709.0.

If the experiment has not been disabled or takes time to propagate then I guess everyone in this boat just needs to wait a bit, but if the experiment has been disabled and the Canary should have picked up the new experiment setting, that implies that disabling the experiment won't/isn't getting hosed Canary users running again.

It hasn't been disabled yet. CCed on internal CL.

Re #44: You need to upgrade Canary to have the fixed version. To be able to do that, follow the steps from comment https://bugs.chromium.org/p/chromium/issues/detail?id=603452#c5

I know how to get the new Canary - my concern is all the Canary users out in the wild who are affected by this bug.

Canary will auto-update when Keystone runs, so there shouldn't be an issue.

Thank you - it did finally update.

I confirm it works for me now, Version 52.0.2709.0 canary (64-bit)
thank you all :)

Before you turn the experiment back on, but after https://codereview.chromium.org/1890043002/ has landed, I'd like to reland my change that removes POSIX shared memory. I would hate to have to revert that again because mojo doesn't handle null Mach ports correctly.

Just ping me when you want me to turn it back on. It's off now as you probably already saw - forgot to update this bug earlier.

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

commit 7bd80f207b67368fe1d1b6dc6641406444ae6290
Author: amistry <amistry@chromium.org>
Date: Sat Apr 16 02:25:41 2016

[mojo-edk] Support transferring null Mach ports.

BUG= 603452 

Review URL: https://codereview.chromium.org/1890043002

Cr-Commit-Position: refs/heads/master@{#387797}

[modify] https://crrev.com/7bd80f207b67368fe1d1b6dc6641406444ae6290/mojo/edk/embedder/embedder_unittest.cc
[modify] https://crrev.com/7bd80f207b67368fe1d1b6dc6641406444ae6290/mojo/edk/system/channel.cc
[modify] https://crrev.com/7bd80f207b67368fe1d1b6dc6641406444ae6290/mojo/edk/system/channel.h
[modify] https://crrev.com/7bd80f207b67368fe1d1b6dc6641406444ae6290/mojo/edk/system/channel_posix.cc
[modify] https://crrev.com/7bd80f207b67368fe1d1b6dc6641406444ae6290/mojo/edk/system/mach_port_relay.cc

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

commit 21fef176d164d23237563e76a280f5012fd5c425
Author: erikchen <erikchen@chromium.org>
Date: Mon Apr 18 18:39:15 2016

Remove POSIX shared memory.

The first attempt to land this CL was reverted because it tickled a Mojo bug
(Mojo couldn't handle null Mach ports). That has since been fixed:
https://codereview.chromium.org/1890043002/

Original CL: https://codereview.chromium.org/1867733002/

BUG= 603452 
TBR=mark@chromium.org,mseaborn@chromium.org,avi@chromium.org,tsepez@chromium.org,amistry@chromium.org,thakis@chromium.org

Review URL: https://codereview.chromium.org/1897623002

Cr-Commit-Position: refs/heads/master@{#387967}

[modify] https://crrev.com/21fef176d164d23237563e76a280f5012fd5c425/base/memory/shared_memory.h
[modify] https://crrev.com/21fef176d164d23237563e76a280f5012fd5c425/base/memory/shared_memory_handle.h
[modify] https://crrev.com/21fef176d164d23237563e76a280f5012fd5c425/base/memory/shared_memory_handle_mac.cc
[modify] https://crrev.com/21fef176d164d23237563e76a280f5012fd5c425/base/memory/shared_memory_mac.cc
[modify] https://crrev.com/21fef176d164d23237563e76a280f5012fd5c425/base/memory/shared_memory_unittest.cc
[modify] https://crrev.com/21fef176d164d23237563e76a280f5012fd5c425/components/nacl/loader/nacl_ipc_adapter.cc
[modify] https://crrev.com/21fef176d164d23237563e76a280f5012fd5c425/content/renderer/media/video_capture_message_filter_unittest.cc
[modify] https://crrev.com/21fef176d164d23237563e76a280f5012fd5c425/ipc/ipc_message_utils.cc
[modify] https://crrev.com/21fef176d164d23237563e76a280f5012fd5c425/mojo/edk/embedder/embedder_unittest.cc
[modify] https://crrev.com/21fef176d164d23237563e76a280f5012fd5c425/mojo/edk/embedder/platform_shared_buffer.cc
[modify] https://crrev.com/21fef176d164d23237563e76a280f5012fd5c425/mojo/edk/embedder/platform_shared_buffer_unittest.cc

+ Ligi as this is RB for M52 dev this Thur

I enabled ChannelMojo on the latest canary (52.0.2712.0) which contains the posix shm removal and did some browsing and scrolling. Everything looks good.