Chromium bug on Debian AppVMs with latest kernel (not reproducible on "bare metal" fresh install and updated Debian)

[tonsimple]

Qubes OS version (e.g., R3.2):

3.2

Affected TemplateVMs (e.g., fedora-23, if applicable):

Debian 8

---

Expected behavior:

Chromium working with google maps as expected

Actual behavior:

Google maps page goes insane and is corrupted, browser doesn't crash or lag though, just google maps becoming scrambled.

http://imgur.com/a/BY83b

The log (if chromium is launched from command line) has the following to say:

[1:12:0426/171246.938521:ERROR:WaitUntilObserver.cpp(147)] Not implemented reached in void blink::WaitUntilObserver::reportError(const blink::ScriptValue &)
[1654:1681:0426/171256.865491:ERROR:ssl_client_socket_impl.cc(1136)] handshake failed; returned -1, SSL error code 1, net_error -100
[1796:1796:0426/171300.614560:ERROR:child_thread_impl.cc(762)] Request for unknown Channel-associated interface: ui::mojom::GpuMain

Steps to reproduce the behavior:

Have a Debian 8 app-vm with all updates and stuff.

Launch chromium. Go search for an address, any address, and try to wiggle the map around.

Issue happens.

Reproduced on Qubes on laptop (where the screenshot is coming from) and later, when I returned from travel, on my desktop Qubes.

Tried reproducing it on a "normal" debian installed on bare metal and did not succeed so I suspect this might be legitimately a Qubes thing.

General notes:

---

Related issues:

[rtiangha]

We need a central place to keep track of all this since this SSL thing is spread across at least 3 tickets.

But anyway, what kernel are you running, and is there an older kernel still on your system that this reliably doesn't happen on? I need more data to figure out if this is really a kernel issue and if so, where it started.

[rtiangha]

We need a central place to keep track of all this since this SSL thing is spread across at least 3 tickets.

But anyway, what kernel are you running, and is there an older kernel still on your system that this reliably doesn't happen on? I need more data to figure out if this is really a kernel issue and if so, where it started.

[rtiangha]

Also, list of templates used in sys-net, sys-firewall and AppVM, just to rule out template updates or incompatibilities between the interactions of different distros; it could be a distro update was pushed out by a distro recently that's causing this too. I do think it's something very recent, though.

[rtiangha]

Also, list of templates used in sys-net, sys-firewall and AppVM, just to rule out template updates or incompatibilities between the interactions of different distros; it could be a distro update was pushed out by a distro recently that's causing this too. I do think it's something very recent, though.

[rtiangha]

And NIC hardware too, just as a sanity check and to rule out a driver regression.

[rtiangha]

And NIC hardware too, just as a sanity check and to rule out a driver regression.

[andrewdavidwong]

@rtiangha:

We need a central place to keep track of all this since this SSL thing is spread across at least 3 tickets.

I see #2840, but which is the third one?

Also, are you sure all three are duplicates? If not, I don't think they should be collapsed into a single ticket.

[andrewdavidwong]

@rtiangha:

We need a central place to keep track of all this since this SSL thing is spread across at least 3 tickets.

I see #2840, but which is the third one?

Also, are you sure all three are duplicates? If not, I don't think they should be collapsed into a single ticket.

[rtiangha]

@andrewdavidwong Maybe you're right; there was another thread about kernel issues that came in around the same time but it turned out not to be specifically about SSL per se; that was probably the third one in my head. Plus there was the stuff on qubes-users too, so it was a lot to try to keep track of.

Anyway, I think 2840 should be the central place since it affects more than Chromium, and since the source has now been found, can be set to resolved once a new kernel update has been officially pushed out.

[rtiangha]

@andrewdavidwong Maybe you're right; there was another thread about kernel issues that came in around the same time but it turned out not to be specifically about SSL per se; that was probably the third one in my head. Plus there was the stuff on qubes-users too, so it was a lot to try to keep track of.

Anyway, I think 2840 should be the central place since it affects more than Chromium, and since the source has now been found, can be set to resolved once a new kernel update has been officially pushed out.

[andrewdavidwong]

Right, but it's still not clear to me that this issue (#2778) is a duplicate of #2840. If it's not, I think it should remain open.

[andrewdavidwong]

Right, but it's still not clear to me that this issue (#2778) is a duplicate of #2840. If it's not, I think it should remain open.

[rtiangha]

@andrewdavidwong: Good point.

@tonsimple: What kernel version are you running in this VM?

[rtiangha]

@andrewdavidwong: Good point.

@tonsimple: What kernel version are you running in this VM?

[tonsimple]

@rtiangha
Just reproduced it on Debian-8 based AppVM, kernel version 4.4.62-12

[tonsimple]

@rtiangha
Just reproduced it on Debian-8 based AppVM, kernel version 4.4.62-12

[tonsimple]

(also, for what it's worth, everything works without any issue in Firefox on same appvm)

[tonsimple]

(also, for what it's worth, everything works without any issue in Firefox on same appvm)

[rtiangha]

I can't replicate on my machine, and there aren't any video card changes in that kernel version if previous versions were working fine, or the SSL problem that was affecting the latest kernel versions that were recently released so it's probably not a kernel issue. It could be video settings since the logs show a complaint about GpuMain and the screen shot looks like a display problem anyway.

Go to Settings->Show Advanced Settings and scroll to the bottom.

Is "Use hardware acceleration when available" checked? If so, uncheck it, restart Chromium and report back if the issue persists or not.

If it isn't checked, try launching Chromium from the command line with LIBGL_ALWAYS_SOFTWARE=1 and report back.

So:

LIBGL_ALWAYS_SOFTWARE=1 chromium

[rtiangha]

I can't replicate on my machine, and there aren't any video card changes in that kernel version if previous versions were working fine, or the SSL problem that was affecting the latest kernel versions that were recently released so it's probably not a kernel issue. It could be video settings since the logs show a complaint about GpuMain and the screen shot looks like a display problem anyway.

Go to Settings->Show Advanced Settings and scroll to the bottom.

Is "Use hardware acceleration when available" checked? If so, uncheck it, restart Chromium and report back if the issue persists or not.

If it isn't checked, try launching Chromium from the command line with LIBGL_ALWAYS_SOFTWARE=1 and report back.

So:

LIBGL_ALWAYS_SOFTWARE=1 chromium

[tonsimple]

@rtiangha
Hm, un-ticking the "Use hardware acceleration when available" solved it.

I wonder why this manipulation is not necessary in fedora-based VMs

[tonsimple]

@rtiangha
Hm, un-ticking the "Use hardware acceleration when available" solved it.

I wonder why this manipulation is not necessary in fedora-based VMs

[rtiangha]

WebGL doesn't work in Qubes because OpenGL doesn't work in Qubes (never has). When that option is checked, sometimes Chrome/Chromium can detect that and switch to software rendering properly. But I remember seeing a bug somewhere where one version of Chrome couldn't (that detection feature may have gotten fixed in a future version). Actually, I wouldn't be surprised if the Chromium version in Debian 8 isn't the same as the Fedora one; the Fedora one is probably newer (so too is the version in Debian 9).

Either way though, regardless if that option is checked, it's supposed to use the software renderer in both cases so in essence, that option is useless in Qubes. But as this issue shows, easiest thing is to just leave it unchecked.

[rtiangha]

WebGL doesn't work in Qubes because OpenGL doesn't work in Qubes (never has). When that option is checked, sometimes Chrome/Chromium can detect that and switch to software rendering properly. But I remember seeing a bug somewhere where one version of Chrome couldn't (that detection feature may have gotten fixed in a future version). Actually, I wouldn't be surprised if the Chromium version in Debian 8 isn't the same as the Fedora one; the Fedora one is probably newer (so too is the version in Debian 9).

Either way though, regardless if that option is checked, it's supposed to use the software renderer in both cases so in essence, that option is useless in Qubes. But as this issue shows, easiest thing is to just leave it unchecked.