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

Bug #1696965 reported by Olivier Tilloy on 2017-06-09
This bug affects 1 person
Affects Status Importance Assigned to Milestone
chromium-browser (Ubuntu)
Olivier Tilloy

Bug Description

Chromium 59.0.3071.86 was promoted to the stable release channel earlier this week, and I have built packages for all supported ubuntu releases at

While they seem to work well on bare metal and in virtualbox virtual machines, we are seeing an issue in KVM guests (e.g. Ubuntu 16.04.2): when launched, the page in the first tab is not rendered at all (the contents remain blank). Refreshing the page doesn't make things any better. But browsing to a different domain in the same tab "fixes" the issue.

All URLs are affected: the default URL when opening the browser for the first time is chrome://welcome, and it's not rendered, and so aren't other http URLs when passed on the command line.

It looks like the first renderer process is not able to render to screen correctly. The renderer process itself looks okay, it doesn't crash, and I haven't seen anything relevant in the verbose logs.

The official google chrome release on the same configuration is affected too, although much less often.

Olivier Tilloy (osomon) on 2017-06-09
Changed in chromium-browser (Ubuntu):
assignee: nobody → Olivier Tilloy (osomon)
importance: Undecided → Critical
Mikhail Novosyolov (mikhailnov) wrote :

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?

Olivier Tilloy (osomon) wrote :

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.

Olivier Tilloy (osomon) wrote :

Packages built by Saikrishna Arcot at are also affected.

Olivier Tilloy (osomon) wrote :

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).

Olivier Tilloy (osomon) wrote :

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.

Olivier Tilloy (osomon) wrote :

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.

Olivier Tilloy (osomon) wrote :

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

Olivier Tilloy (osomon) wrote :

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.

Olivier Tilloy (osomon) wrote :

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.

Olivier Tilloy (osomon) wrote :

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

Olivier Tilloy (osomon) wrote :

Version 59.0.3068.0 is not affected.

Olivier Tilloy (osomon) wrote :

Version 59.0.3068.4 is not affected, version 59.0.3069.0 is.
There are 448 commits in that window (
There are no more intermediate release tags to bisect on.

Olivier Tilloy (osomon) wrote :

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.

Olivier Tilloy (osomon) wrote :

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.

Olivier Tilloy (osomon) wrote :

And for reference, the commit that introduced the problem is

Changed in chromium-browser (Ubuntu):
status: New → In Progress
Olivier Tilloy (osomon) wrote :

« 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.

Changed in chromium-browser (Ubuntu):
importance: Critical → High
Olivier Tilloy (osomon) on 2017-06-22
description: updated
Olivier Tilloy (osomon) wrote :
Changed in chromium-browser (Ubuntu):
status: In Progress → Confirmed
Olivier Tilloy (osomon) wrote :

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?

Olivier Tilloy (osomon) wrote :

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.

Olivier Tilloy (osomon) on 2018-03-27
Changed in chromium-browser (Ubuntu):
status: Confirmed → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Bug attachments