Page 1 of 2

[5.2.0] OpenGL Warning: vboxCall failed with VBox status code VERR_BUFFER_VERFLOW

Posted: 20. Nov 2017, 00:04
by Kjetil
Hi,

Seems like OpenGL is not working at all for me after upgrading. I just upgraded from 5.1.14 to 5.2.0. I'm running Windows 7sp1 in a Linux host (fedora core 17).

To reproduce, run the glxgears.exe program found here: http://www2.cs.uidaho.edu/~jeffery/win32/ (remove spaces manually from the link, the system didn't allow me to post urls)

Here's the output:

Code: Select all

OpenGL Warning: vboxCall failed with VBox status code VERR_BUFFER_VERFLOW
OpenGL Warning: SHCRGL_GUEST_FN_WRITE_READ (64) failed with ffffffd7 ffffffd7
OpenGL Warning: vboxCall failed with VBox status code VERR_BUFFER_VERFLOW
OpenGL Warning: vboxCall failed with VBox status code VERR_BUFFER_VERFLOW
OpenGL Warning: vboxCall failed with VBox status code VERR_BUFFER_VERFLOW
... etc.

I'm getting the same errors when running my own program: http://users.notam02.no/~kjetism/radium/

I'm running a very old version of Linux in order to make binaries that runs on many linux computers. I rather not want to upgrade. I could run a newer version of windows though, if that would help. Installing VBoxGuestAdditions_5.2.1-118918.iso did not help.

Anything else to try?

Thanks!

Re: [5.2.0] OpenGL Warning: vboxCall failed with VBox status code VERR_BUFFER_VERFLOW

Posted: 20. Nov 2017, 09:59
by Kjetil
Guess I wasn't very clear:

1. No OpenGL program starts up as far as I can see. They freeze while error messages are printed to the console (if it's a console program).
2. The error messages (OpenGL Warning: vboxCall failed with VBox status code VERR_BUFFER_VERFLOW) are printed to the windows console, NOT the linux console.

Doesn't anyone else see this? OpenGL worked fine in 5.1.14.

Re: [5.2.0] OpenGL Warning: vboxCall failed with VBox status code VERR_BUFFER_VERFLOW

Posted: 20. Nov 2017, 10:59
by mpack
Please provide a VM log file. With the VM fully shut down, right click it in the GUI. Select "Show Log" and save "VBox.log" (ONLY) to a zip file. Attach the zip here.

Re: [5.2.0] OpenGL Warning: vboxCall failed with VBox status code VERR_BUFFER_VERFLOW

Posted: 20. Nov 2017, 12:43
by Kjetil
Log is attached. I started windows 7, ran the glxgears program, and shut down. After that I saved log file.

Re: [5.2.0] OpenGL Warning: vboxCall failed with VBox status code VERR_BUFFER_VERFLOW

Posted: 20. Nov 2017, 13:30
by mpack
Unfortunately your glxGears link is dead for me. I'll try to find some other app that I know for sure uses OpenGL rather than Direct3D.

Re: [5.2.0] OpenGL Warning: vboxCall failed with VBox status code VERR_BUFFER_VERFLOW

Posted: 20. Nov 2017, 13:39
by Kjetil

Re: [5.2.0] OpenGL Warning: vboxCall failed with VBox status code VERR_BUFFER_VERFLOW

Posted: 20. Nov 2017, 13:46
by mpack
I just tried an OpenGL viewer of my own, and it just locks up, using all of one core in an XP VM. Some commercial 3D modeling software does the same thing, but I'm not certain whether that's Direct3D or OpenGL. The 3D software used to work (though badly), in fact that's why that VM exists.

This discussion belongs in the 5.2.0 discussion topic.

Re: [5.2.0] OpenGL Warning: vboxCall failed with VBox status code VERR_BUFFER_VERFLOW

Posted: 20. Nov 2017, 13:46
by Martin
I've downloaded the EXE and attach it here in a zip file.

Re: [5.2.0] OpenGL Warning: vboxCall failed with VBox status code VERR_BUFFER_VERFLOW

Posted: 20. Nov 2017, 13:56
by mpack
Thanks Martin.

Ok, I can confirm that I too get a stream of buffer overflow messages when I run glxGears in my XP VM.

Re: [5.2.0] OpenGL Warning: vboxCall failed with VBox status code VERR_BUFFER_VERFLOW

Posted: 22. Nov 2017, 07:20
by KPeg
Hi there,

Another post mentioned the same issue on Linux Guest VM and a temporary fix is available:
Hi,

First, I tried Firefox after the upgrade of VBox 5.2 and I could not open up Firefox window at all. Rolling back to previous versions of Firefox would not work either.

Reinstalling Gnome desktop and everything did not help. I almost had to reinstalled the whole system to get things work.

Fortunately, I discovered that OpenGL is not working when I tested against 3D acceleration feature on my CentOS 6.9 Guest VM.

Initially, the upgrade of Guest Addition to the latest 5.2.1-118918 release via iso file would not work.

GUI Desktop looks okay but web browser like Firefox would never open up. Also, it stayed in memory forever and occupied certain CPU resources. I had to use killall to take those processes out.

With command like glxinfo, it pops up lots of replicated error messages as the subject mentioned above.

The following command would never work until I shut down the VM, turned off 3D acceleration feature and then restart again. Viola! Things work again!
CODE: SELECT ALL EXPAND VIEW

Code: Select all

$ glxinfo | grep opengl
Once 3D acceleration is off, the linux VM behaves as it used to be. But, the thing is I really want to make use of OpenGL for graphic acceleration and so on. Can any VBox expert come out and fix this? :D
Bad thing is that Gamers may not be happy with this solution :cry: .

Re: [5.2.0] OpenGL Warning: vboxCall failed with VBox status code VERR_BUFFER_VERFLOW

Posted: 22. Nov 2017, 11:09
by mpack
I wouldn't call that a fix, or a solution! 3D acceleration seems to be broken. If your VM needs 3D acceleration then disabling it will not solve anything.

Re: [5.2.0] OpenGL Warning: vboxCall failed with VBox status code VERR_BUFFER_VERFLOW

Posted: 22. Nov 2017, 17:04
by Kjetil
KPeg wrote:Once 3D acceleration is off, the linux VM behaves as it used to be. But, the thing is I really want to make use of OpenGL for graphic acceleration and so on. Can any VBox expert come out and fix this? :D
The situation is slightly better on Windows. Everything works there, except if you try to run OpenGL or 3D programs, so this temporary fix doesn't fix anything. (Also, for the record, my program is a 2D OpenGL program, but it behaves the same way, so the problem is not directly applicable to 3D.) Downgrading VirtualBox to 5.1.30 is a working fix though.

Re: [5.2.0] OpenGL Warning: vboxCall failed with VBox status code VERR_BUFFER_VERFLOW

Posted: 22. Nov 2017, 19:23
by mpack
Kjetil wrote: The situation is slightly better on Windows. Everything works there, except if you try to run OpenGL or 3D programs
Actually, people have been reporting corruption problems in Windows 10 as well, especially in windows with animated content, such as the active content of the start menu. I don't know if this corruption persists with 2D/3D acceleration disabled.

Re: [5.2.0] OpenGL Warning: vboxCall failed with VBox status code VERR_BUFFER_VERFLOW

Posted: 23. Nov 2017, 03:03
by KPeg
Kjetil wrote:
KPeg wrote:Once 3D acceleration is off, the linux VM behaves as it used to be. But, the thing is I really want to make use of OpenGL for graphic acceleration and so on. Can any VBox expert come out and fix this? :D
The situation is slightly better on Windows. Everything works there, except if you try to run OpenGL or 3D programs, so this temporary fix doesn't fix anything. (Also, for the record, my program is a 2D OpenGL program, but it behaves the same way, so the problem is not directly applicable to 3D.) Downgrading VirtualBox to 5.1.30 is a working fix though.
Thanks Kjetil, it works :o ! I can confirm that installing VBoxGuestAdditions_5.1.30.iso on Linux Guest VM resolved the issue for me. Firefox is now opened without an issue and the command like glxinfo displays the output text as expected.

I might stick with VBoxGuestAdditions_5.1.30.iso until the 5.2 stream is repaired properly. Thankyou guys for the advice :D !

Re: [5.2.0] OpenGL Warning: vboxCall failed with VBox status code VERR_BUFFER_VERFLOW

Posted: 20. Dec 2017, 13:17
by mpack
I'm glad to say that this problem appears to be fixed for me in 5.2.4, with the 5.2.4 GAs installed in safe mode, Direct3D support enabled, 2D and 3D acceleration enabled in the VM settings.

Result :

DxDiag no longer hangs. glxGears gives a single buffer error but then works. A CAD package I have which was hanging now works again, kinda (I.e. it now runs as badly in a VirtualBox VM as it always did).