Description

Starting from 5.0.16 theres been graphics artifacts which hang the desktop (Gnome 3) on a Ubuntu 14.04 guest with the latest Xenial LTS kernel (4.4) and guest additions installed on a Windows 7 64bit host.

The graphics artifacts effectively start after you open Chome and even restarting Gnome 3 doesnt resolve the artifacts. This partially happened in 5.0.14 but only for a few seconds when you initially open Chrome and then it goes away and is usable. From 5.0.16/20 this pretty much makes the GUI desktop unusable once you open Chrome.

This is starting to get more pronounced and annoying on 5.0.14 . Im not sure if Chrome or my kernel got updated in the last day or two but its currently starting to destabilize my system at after a bit on 5.0.14 whereas before it would work fine aside from some minor artifacts when I first opened Chrome.

Ive attached some logs from 5.0.14 (unfortunately I dont have cycles to upgrade back to 5.0.20 to gather logs) so hopefully this will maybe help shed some light on something. Also not sure if the default log level is verbose enough or if theres a way to turn it up.

@frank: This happens with 5.0.14 but its not easy to reproduce as it is on 5.0.20 and I submitted logs for 5.0.14 because I use this for work and thats the newest version that was stable enough for me to get work done on. I hadnt had a chance to go back and collect logs.

The state of this bug on 5.0.14:

Reproducing the GUI artifacts with Chrome alone is difficult. When you first open Chrome, you get a bunch of black flickering and then the Ubuntu reporting tool kicks in about an issue and from there on for the most part the browser (including video on Youtube) usually works without further artifacts or crashing the desktop overall.

Reproducing these artifacts is easier and consistent if you use VLC to play a video however. If you open VLC and play a video for a few seconds while opening a bunch of windows and minimizing/maximizing back and forth you will still see the VLC video playing in the foreground even though you have minimized VLC. Once you attempt to close VLC, the full desktop artifacts kick in and you cant do anything except a hard reboot.

The state in 5.0.20:

Opening Chrome is enough to start the full desktop artifacts to the point that the only thing you can do is a hard reboot.

On a side note since the VLC behavior seems to be keeping the video render in the foreground even when minimized, I have seen another oddity with modal windows being forced into the foreground and making the parent window disappear (which does not happen when on a Linux host) until you close the modal window.

I normally see this behavior when using KeepassX and I open the modal for editing the properties of one of the entries. In normal unvirtualized Linux host you can still see the parent window behind the modal when that modal is open, but in 5.0.14, that modal is the only thing that remains visible.

I dont know if this is a separate bug or not but adding here just in case it helps due to the behavior of the VLC video render.

Seeing this on Centos 7 too, with VirtualBox 5.20. Opening Chrome seems to corrupt the display. To save a restart, it is sometimes possible to hit Alt+F4 to close Chrome, and then resize the window to force a redraw.

If you are confident that this issue falls into this category, can you tell me if you think disabling 3D acceleration will at least allow me to use the desktop without the artifacts? I can test this out but on my Windows host machine it takes me 20-30 min to uninstall/reboot/upgrade and the same to revert. Id rather have to try only to find out im going to probably get the same behavior.

If you are confident that this issue falls into this category, can you tell me if you think disabling 3D acceleration will at least allow me to use the desktop without the artifacts? I can test this out but on my Windows host machine it takes me 20-30 min to uninstall/reboot/upgrade and the same to revert. Id rather have to try only to find out im going to probably get the same behavior.

I expect that it would. Is stopping the guest and restarting it with the 3D acceleration tick box disabled such a bit thing to try though? If it is, other user reports suggest that just starting Chromium with a particular command line switch for disabling its use of 3D tends to fix the problem.

I think this affecting me too, if my case applies, this problem is still affecting v5.0.22.

Win7Pro host, Fedora 23 guest. When 3D acceleration is enabled, and I start Google Chrome in the guest, the viewing area for this (as well as all apps I start afterwards) are unviewable. If I shutdown the guest, disable 3D acceleration, and restart the guest, when I run Google Chrome, it works fine.

I haven't sought support on this problem before, figuring it was a big enough deal that it would get addressed in some future release. But .18, .20, and .22 has come out and is still a problem. Last working release was .16.

Removed several "me too" comments and added the commenters to the CC list.

Current status: the VirtualBox development team does not have enough spare resources for working on the current 3D implementation for X11 guests (all developers who would be qualified have too many other things to do for the foreseeable future). We would be able to integrate fixes provided by users as long as they are convincing (e.g. the person providing the fix can explain why it works, not just "I changed this and it seemed to do the trick") and properly tested (we could provide builds for other users to test).

Please see the wiki page regarding user contributions to X11 guest 3D support. Any one with reasonable experience at debugging 3D applications has a good chance of getting this fixed. Anyone who has those skills and is interested should take a look at the code and write to the vbox-dev mailing list<1> if they need help with VirtualBox specifics.

Current known work-arounds for this issue: see comment:15; alternatively disable 3D in the guest.

Some people have used 5.0.16 Additions, but this is not really recommended: 3D in Chromium just does not work at all with those Additions, but you can just as well use current Additions and disable 3D in Chromium; additionally those Additions do not support the newest guests.

I am currently experiencing similar issue with Virtual Box 5.1.14 on Windows 7 64-Bit and Guest OS: Ubuntu 16.04 with latest updates.

In my case the chromium-browser completely nukes the Ubuntu desktop rendering. But sometimes moving between full-screen and windowed mode forces a redraw which helps in bringing back the Desktop occasionally.

For disabling hardware acceleration support in chromium-browser I am using terminal to launch the chromium browser.

$ chromium-browser --disable-gpu

For me the other OpenGL apps like glxgears works without any issues.

I have also uploaded the chromium-crash log with hardware acceleration enabled.

Since this is a crash it might make sense to open a new ticket for it. Please describe exactly how you trigger the crash (it did not trigger for me). Also, you could try rebuilding the Guest Additions locally<1> to get debug symbols for the OpenGL library in the crash trace. Please make sure you do a release build by adding "BUILD_TYPE=release" on the kmk command line.

Note: It will ask to restart the Chromium browser in case the option is disabled, just close the window.

Now from a terminal window start the chromium browser.

$ chromium-broswer

Note 1: You might have to open and close the browser window multiple times to trigger the issue.Note 2: You might want to redirect the stdout, stderr stream to some log file for capturing the crash report.Note 3: Sometimes even if the crash report is generated the chromium-browser still functions without any issues.

For rebuilding the Guest Additions do you mean to build in Debug mode? as you have mentioned:

"Please make sure you do a release build by adding "BUILD_TYPE=release" on the kmk command line."

Can you provide the build steps as I am seeing lot of build requiring 32-bit libraries?
Currently I am having the Guest OS: Ubuntu 16.04 64-Bit where currently I do-not have any 32-Bit development libraries installed.

I really meant a release build - it will still have the debug symbols, but will not abort due to assertions. Unfortunately the configure script asks for lots of dependencies that are not needed for the Additions, probably the easiest way to deal with that is just to add all the "--without" flags you can find and to install libraries which the build complains about. The command to build the Additions would be:

kmk BUILD_TYPE=release VBOX_ONLY_ADDITIONS

Rather than build the installer ISO, you could just look for VBoxOGL.so under out/linux.amd64/debug/obj and copy that onto the guest over the existing one. The copy in that place should be the one without debug information stripped out.

I have noticed the same problem with electron based applications like vscode and gitkraken which is in fact are chrome based application when 3D hardware acceleration is enabled.
Currently i'm using VB 5.1.18 + VB Extension 5.1.18 + VB Guest Additions 5.1.18 on my Window 7 Host. The Guest OS is Ubuntu 16.04. I have figured out that that with VB Guest Additions 5.1.10 everthing works fine but all higher versions lead to black window artifacts.