3D support must be disabled, otherwise VMs won't start

[socratis]

• Host: OSX 10.9.5.
• Guest: Any with 3D acceleration enabled.

The summary says it all pretty much. If you enable 3D acceleration on any VM, the Display settings are "Invalid":

Display: Screen page:
The virtual machine is set up to use hardware graphics acceleration. However the host system does not currently provide this, so you will not be able to start the machine.

On top of that if you try to start the VM, w/o realizing that the settings need to be changed, you get:

Failed to open a session for the virtual machine Windows 7.
This VM was configured to use 3D acceleration. However, the 3D support of the host is not working properly and the VM cannot be started. To fix this problem, either fix the host 3D support (update the host graphics driver?) or disable 3D acceleration in the VM settings (VERR_NOT_AVAILABLE).

    Result Code: NS_ERROR_FAILURE
                 (0x80004005)
    Component:   ConsoleWrap
    Interface:   IConsole
                 {872da645-4a9b-1727-bee2-5585105b9eed}

[socratis]

Installer log. Nothing weird.

[socratis]

A typical VBox.log, this one from a Mint 17 (64-bit).

[socratis]

It seems the offending line is (the 2nd):

00:00:01.859264 OpenGL: Offline rendering support is OFF (pid=15562)
00:00:01.859301 OpenGL Info: 3D test unable to choose pixel format (internal error).

That's what's different from previous logs at least, where the same lines were:

00:00:03.379929 OpenGL: Offline rendering support is OFF (pid=53730)
00:00:03.380618 OpenGL Info: 3D test passed

[frank]

Confirmed. This is indeed a 5.1.20 regression which hopefully affects only Mac OS X hosts but in theory other hosts might be affected as well. 5.1.20 contains checks to prevent loading of certain libraries. This check made the 2D+3D availability test always fail.

We replaced the official 5.1.20 114628 build for Mac OS X by 5.1.20 114629. 5.0.38 is affected as well. The updated 5.0.38 build will be named 5.0.38 114633 and will be available in about 1h from now.

Please reopen if you can reproduce the problem with 5.1.20 114629. In that case, please attach the VBox.log file of such a VM session.

[socratis]

Confirmed as fixed with build >= 114629.

Thanks for the quick turnaround!