First renderer process doesn't render page for chromium 59.0.3071.86 in KVM

Google compiles Chrome using Clang, but the Ubuntu packages is built using gcc, ofc ourse, it should not be the reason of the bug, but still why not to swith to clang?

Are VAAPI patches applied to the ubuntu package? Maybe they are the reason?

The packages on zesty and above are built using clang, yet they are also affected by this issue.
Chromium requires clang >= 4.0 to build, and this is not available in yakkety and below (it just got backported to xenial, currently in -proposed, but it's not available in trusty).

VAAPI patches are not applied anywhere currently.

Packages built by Saikrishna Arcot at https://launchpad.net/~saiarcot895/+archive/ubuntu/chromium-beta are also affected.

Version 59.0.3071.71 (which is as far back as I can go in the chromium-next PPA's history because older packages were purged) is also affected (confirmed in trusty and zesty VMs).

I rebuilt version 59.0.3071.15 in a separate PPA, and that version is also affected.
That means that the regression likely comes from an upstream change, not a packaging change.

I built version 58.0.3029.145 in a PPA, and it's not affected by the issue.
I also built version 59.0.3030.0 in a PPA, and it's not affected either.

That means the regression happened sometime between 59.0.3030.0 and 59.0.3071.15.

There are 9750 commits in that window, need to bisect further.

I built version 58.0.3059.0 in a PPA, and it's not affected by the issue.

That means the regression happened sometimes between 58.0.3059.0 and 59.0.3071.15. Will continue to bisect.

I built version 59.0.3065.0 in a PPA, and it's not affected by the issue.
I built version 59.0.3071.0 in a PPA, and it is affected by the issue.

That means the regression happened sometimes between 59.0.3065.0 and 59.0.3071.0. There are 1895 commits in that window. Will continue to bisect.

Version 59.0.3067.0 is not affected, version 59.0.3069.0 is affected. There are 757 commits in that window.

Version 59.0.3068.0 is not affected.

Version 59.0.3068.4 is not affected, version 59.0.3069.0 is.
There are 448 commits in that window (https://chromium.googlesource.com/chromium/src/+log/59.0.3068.4..59.0.3069.0?pretty=fuller&n=10000).
There are no more intermediate release tags to bisect on.

Launching chromium-browser with --use-gl=ANYSTRING (ANYSTRING really being any string, including invalid GL implementation names such as "foobarbaz", or valid ones such as "swiftshader") makes the issue go away.

Note that when passing an invalid GL implementation name, swiftshader appears to be used, so this is the fallback option.

But launching with chromium-browser --use-gl=any, the issue happens again.

And I can (sometimes) observe a similar issue with google-chrome when launched with --use-gl=any.

And for reference, the commit that introduced the problem is https://chromium.googlesource.com/chromium/src/+/d85baf0b71c69bbd181aaefc8a803611e03c8eed

« The official google chrome release on the same configuration is not affected, so this problem is specific to our chromium-browser packages. »

This is in fact not true. While it happens less often, I've been able to reproduce the issue with google chrome launched without any additional command-line flags. Attaching a screenshot.

Bug reported upstream: https://bugs.chromium.org/p/chromium/issues/detail?id=735947

The issue appears to be fixed in the dev channel, but is still present in the beta channel (see comments on upstream bug report).

Just curious to better understand how stable packages get to the repositories, does this bug block Chromium 59 from being moved to mainline repositories?

Given that the issue seems to be observable only in KVM guests, and that it's not going to be fixed upstream in the stable branch: no this won't prevent chromium 59 from moving to -updates. This should happen real soon now.