Memory leak using Virtualbox / Nvidia driver


This isn’t specifically an OpenSUSE problem I don’t think but I’m not sure which project to raise the issue with and I’d appreciate assistance with anyone here who better understands the problem. I’d like to be able to gather enough information about the problem to be able to raise it with the correct people and with the necessary supporting info.

The problem is this. I run 42.3 as host OS, Oracle VirtualBox v5.2.8 and a Windows 7 guest. I also have the proprietary Nvidia drivers installed (384.111). While the VirtualBox guest machine is running, memory used by the X process increases steadily to the point where it occupies all available RAM and KDE crashes (the error is with kcmserver if that matters). X memory usage is currently at 243,884K, after logging out of KDE approximately an hour ago, logging back in and starting the VM guest.

This error has existed since upgrading from VirtualBox 4, and I can’t now installed v4, because the kernel drivers will not compile on my kernel version (4.4.104-39-default).

I’ve tried disabling 3D acceleration in the guest and that doesn’t resolve the issue.

Closing the VM does not free up the occupied memory, it requires X to be killed (or the DE to be logged out which achieves the same thing). Due to this fact the one support ticket about this issue I found on the VirtualBox bug tracker pointed the finger at the X server (which I think is Xorg?)

Can anyone help identify what the problem might be and how I go about resolving it?

Many thanks.

To me it looks as if this is something you need the virtualization users/experts. Thus why isn’t this in the Virtualization sub-forum?

(When, you after thinking it over, think it should be there, please ask me and do NOT start a double post).

If you think it should be in the virtualisation forum, I’m more than happy for you to move it there. Identifying which level of the stack may be responsible for the problem has been the biggest challenge in me finding the right place to ask, which is why I came here.

Well, you are searching for people with experience in your subject. As I read it you use terms related to virtulisation very often. Non virtualisation people like me will stop reading your thread after the fourth word in the title. But I assume people visiting the Virtualization sub-forums will have the urge to open the thread ;).

This will be moved and is CLOSED for the moment.

Moved from Applications and open again.

If you hardware supports virtualization, then I would suggest creating a KVM test machine with libvirt/qemu and see if it duplicates on the host, then at least you can eliminate the virtualization technology in use…

First,** regarding your problems running current Virtualbox…**

Aside from broadly testing different virtualization technologies as Malcolm suggests,

I’d start with your conclusion that you have an X server memory leak. Aside from whether you are reading metrics from within your Guest or HostOS(You should do both), it’s also a big possibility that some other app besides VBox is using an X server, too and causing your resource exhaustion.

  • Are you describing the X server in the Guest or the HostOS?
    If in the Host, then you should list all your running applications besides Virtualbox. Run something like top or htop to view other processes/apps running on your machine.
    You should also describe your Host resources (memory + swap primarily) and Guest (same)
    are you running remote graphical connections? Those can increase X server resource usage in a big way.

If you haven’t done any analysis within the Guest, do so.
Same as Host, run top and htop. Does your internal memory usage within the Guest correspond with the increased measurements on the HostOS? If so, can you identify what is happening in the Guest?

Remember that FF is probably the most well known source for memory leaks over the years… largely because of FF plugins. If you’re running FF on either the Host or Guest, don’t during your testing. Or, at least disable all plugins first.

If as a last resort you can’t track down your memory leak, take a look at my article on the Free memory analysis and reporting tool. At the bottom I provide a command that will largely fix your memory usage temporarily without a reboot

As for installing an old version of Virtualbox…
If you want to pursue this, you’ll have to provide details, eg
Source for your Virtualbox, it should come from the Oracle Virtualbox website starting from the following page

Prerequisites are the usual… gcc, make, kernel headers for your current kernel, plus optionally kdms so you don’t have to re-build manually with every kernel update.

I haven’t tried to install an ancient VBox 4.x on a system with a current kernel so don’t know how that would go, but if post any errors you get, there’s a possibility the solution might be generic.


Thanks tsu2, that’s very helpful information.

The problem has been recurring over a number of months (I’d say for over a year), and my observation (unscientific) has been that when my Windows 7 VM is running, I experience the memory leak and when it is not I don’t.

Interestingly, after closing every app I had open, I ran the command shown in your article

sh -c “sync; echo 3 > /proc/sys/vm/drop_caches”

and it did not free the occupied memory.

X is still consuming 4,496,408K on my host.

I do also use Firefox and Chromium, but the memory increase exhibited by the X process only occurs when I have the VirtualBox VM running.

For what it is worth I don’t see the problem here running 5.1.32_SUSE r120294

Where are you getting 5.2.8??

I know this is an old thread, but for future reference, this may help someone.

I frequently run a W7 guest that stays on for many hours, sometimes days, in VBox 5.1.38 from the update repo, nvidia G04 390.67-8.1 x86_64 from the nvidia drivers repo and mesa 17.0.5-176.1 also from the update repo.

Both 2D and 3D acceleration are ticked in the VM settings, paravirtualization interface is set to standard and VT-x/AMD-V enabled (CPU is an i5 4th gen). There’s no memory leak. Perhaps it is (was) a problem related to the Oracle version.