Sign in to add a comment
|
First renderer process doesn't render page in KVM guest | |||||||||||||||||||||
| Reported by olivier....@canonical.com, Jun 22 2017 | Back to list | |||||||||||||||||||||
UserAgent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Ubuntu Chromium/60.0.3112.32 Chrome/60.0.3112.32 Safari/537.36 Steps to reproduce the problem: (bug originally reported as https://launchpad.net/bugs/1696965) While packaging chromium 59 for ubuntu, I noticed that when launched in a KVM guest, most of the time the first tab does not render anything (it remains blank). Refreshing (F5) does not make the page render. Browsing to a different domain in the same tab does make the issue go away (the pages start rendering). This can be observed with the chrome://welcome page when launching the browser for the first time without an existing user profile, or in subsequent launches by passing a URL on the command line, e.g.: "chromium-browser http://example.org". I initially thought this was a chromium-only issue, but I can reproduce with the official deb package for google-chrome-stable (although this happens much less frequently with chrome, and the result isn't completely blank with chrome, it's checkered - I'll attach a screenshot). I bisected to find the revision that introduced the bug, and it appears to be https://chromium.googlesource.com/chromium/src/+/d85baf0b71c69bbd181aaefc8a803611e03c8eed (enabling swiftshader by default). 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, except when ANYSTRING=="any", in which case the issue can be observed. Note that I haven't observed the issue on real hardware or in virtualbox VMs, only KVM seems to be showing the issue. What is the expected behavior? I expect the first page to always render correctly. What went wrong? The first page sometimes doesn't render, and no amount of refreshing will make it render. Navigating to a different domain in the same tab "fixes" the issue. Did this work before? Yes any version before swiftshader was turned on by default in linux builds Chrome version: 59.0.3071.109 Channel: stable OS Version: Ubuntu 17.04 Flash Version:
,
Jun 23 2017
What are the contents of about:gpu from the browser instance where this happens?
,
Jun 23 2017
,
Jun 23 2017
Attaching the contents of chrome://gpu for both chrome and chromium (both at version 59.0.3071.109). They differ slightly. I've also noticed that when the issue happens, opening a new tab then switching back to the first tab that wasn't rendered correctly appears to "fix" the issue, i.e. the first tab is rendered properly.
,
Jun 23 2017
Thank you for providing more feedback. Adding requester "kbr@chromium.org" to the cc list and removing "Needs-Feedback" label. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Jun 23 2017
Can you please try Dev Channel (package google-chrome-unstable)? There have been some recent fixes to SwiftShader's rendering path on Linux and I want to make sure this isn't a duplicate bug.
,
Jun 23 2017
I have tested google-chrome unstable (version 61.0.3135.4-1) and chromium-browser (version 61.0.3128.3 from ppa:osomon/chromium-dev) and the issue appears to be fixed there. Now ideally those changes that fixed the issue would be backported to stable and beta, if they can be identified and cherry-picked easily enough.
,
Jun 23 2017
Thank you for providing more feedback. Adding requester "kbr@chromium.org" to the cc list and removing "Needs-Feedback" label. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Jun 24 2017
capn@ can comment on the feasibility of backporting. Since this is not a security issue it will not be backported to stable, but it may be feasible to do so to beta. (Actually, could you please test beta, too? I think the fix may already have been backported there.)
,
Jun 25 2017
Just tested beta, and the issue still happens. This is version 60.0.3112.40, both google-chrome and chromium-browser (from ppa:osomon/chromium-next) are affected, although the issue still happens much more frequently with chromium than with chrome.
,
Jun 27 2017
I'll look into this more, but note that the SwiftShader patch made two changes: 1) Use SwiftShader for WebGL content when the GPU is blacklisted. 2) When the GPU is blacklisted for WebGL, it is blacklisted for all uses. Since example.org doesn't use any WebGL, it must be affected by the second change. And since the other uses of the GPU don't fall back to using SwiftShader, this is not a SwiftShader specific bug. Instead it appears that some other CPU rendering path has regressed. So I'll try to bisect older versions using --disable-gpu-compositing and/or --disable-gpu-rasterization
,
Jun 30 2017
I was seeing similar for a while on linux with gpu compositing: https://bugs.chromium.org/p/chromium/issues/detail?id=730222 https://bugs.chromium.org/p/chromium/issues/detail?id=585023 also has gpu compositing and I think is the same.
,
Jul 4
We can't install desktop VMs with network access on our workstations, but I was able to partially replace this on a cloud VM. I briefly get the page with four black corners, but then example.org renders fine. It's possible that Chrome Remote Desktop which I'm using to access this VM interferes with the issue and triggers a repaint. Unassigning myself since this doesn't appear to be a SwiftShader specific issue or directly related to its integration. |
||||||||||||||||||||||
| ► Sign in to add a comment | ||||||||||||||||||||||
Components: -UI Internals>GPU>SwiftShader
Labels: M-59