[Solved] OpenGL issue with Xubuntu 14.04 inside VirtualBox

On my workplace, I use Xubuntu in a virtual machine (VirtualBox) in full-screen mode without any problem, at least until last week, when I've upgraded from Saucy Salamander to Trusty Tahr.

At first, everything seemed to work fine, but when I tried to launch Firefox, the whole screen became black and the only way to keep working was switching in windowed mode and then back to full-screen. A similar issue happened with Chromium, with the addition that, when back in full-screen, the browser window was always on top.

I've tried to re-install the guest additions, but without solving the problem. From a quick search on Internet, I've find that this issue was related to OpenGL, but everywhere they recommended to enable 3D acceleration in the virtual machine settings (and in my configuration it was already enabled).

Only this article stands out of from the crowd, suggesting to disable 3D acceleration (even if for solving a different issue). And this is what I did (see image below) and it worked.


Additional Information

Host OS: Windows 7 64 bit
Guest OS: Xubuntu 14.04 32 bit
Virtual Box release: 4.3.10 with Extension Pack

This is the not working OpenGL situation.
$ glxinfo 2>/dev/null | grep OpenGL
OpenGL vendor string: Humper
OpenGL renderer string: Chromium
OpenGL version string: 2.1 Chromium 1.9
OpenGL shading language version string: 4.20
OpenGL extensions:

And this is the situation after disabling 3D acceleration.
$ glxinfo 2>/dev/null | grep OpenGL
libGL error: pci id for fd 4: 80ee:beef, driver (null)
OpenGL Warning: Failed to connect to host. Make sure 3D acceleration is enabled for this VM.
libGL error: core dri or dri2 extension not found
libGL error: failed to load driver: vboxvideo
OpenGL vendor string: VMware, Inc.
OpenGL renderer string: Gallium 0.4 on llvmpipe (LLVM 3.4, 128 bits)
OpenGL version string: 2.1 Mesa 10.1.0
OpenGL shading language version string: 1.30
OpenGL extensions:

Probably if you need to play with some 3D game, this solution will not help you, but for my needs, it's just perfect.

[Solved] D-Bus Method Call Stops Working After Few Days

D-Bus diagram
This is an issue that I've found some months ago. I've set up a communication system using asynchronous calls made with D-Bus. It all seemed to work fine for a couple of days but suddenly the entire mechanism stopped working without returning any error.

I've searched around if there was a known bug or if someone else was having the same issue but without result. For this reason I write here the solution, hoping this can be useful for other developers.

The Situation

This is the sequence:
  1. create a new method call
  2. append the parameters
  3. send it
  4. free the memory.

Or if you prefer the code:
DBusMessage *msg = dbus_message_new_method_call(dest, path, iface, method);
dbus_message_append_args(
 msg,
 DBUS_TYPE_UINT32,  &int_par,
 DBUS_TYPE_STRING,  &string_par,
 DBUS_TYPE_INVALID  // closes the function parameters
);
dbus_connection_send(bus, msg, NULL);
dbus_message_unref(msg);

Quite linear, isn't it? Unfortunately after a while (I've estimated after 50.000/100.000 calls) the wanted method is no more called but no error is returned when the message is sent.

The Solution

My assumption was that some kind of memory limit was reached, so I've read the documentation carefully and I've found the following function:
dbus_message_set_no_reply(msg, TRUE);
Adding it before dbus_connection_send() made the whole system run for weeks without any problem.