Ticket #3375 (closed defect: fixed)

Opened 9 years ago

Last modified 7 years ago

Huge memory leak on VirtualBox 2.0.4_OSE (Ubuntu Intrepid AMD64)

Reported by: AndyHitchman Owned by:
Priority: major Component: other
Version: VirtualBox 2.0.4 Keywords:
Cc: Guest type: Windows
Host type: Linux


Running a Vista 32bit guest on Ubuntu 8.10 64bit.

Physical Memory = 4Gb. Guest Memory = 2Gb.

After a few hours, following only normal work in host (Visual Studio 2008), suddenly all physical memory and all swap is 100% used. Memory allocation seems rapid, rather than slow leak. Host grinds to a halt.

Config and log attached.


Vista DotNet Dev.xml Download (6.0 KB) - added by AndyHitchman 9 years ago.
Guest Configuration
VBox.log.2 Download (47.3 KB) - added by AndyHitchman 9 years ago.
Guest Log
VBox.log Download (49.4 KB) - added by arkainrdk 9 years ago.
Log file generated just minutes ago.

Change History

Changed 9 years ago by AndyHitchman

Guest Configuration

Changed 9 years ago by AndyHitchman

Guest Log

comment:1 Changed 9 years ago by sandervl73

It's not really useful to report such things for old versions. Retry with 2.1.4 or at least 2.0.6.

comment:2 Changed 9 years ago by arkainrdk

I can confirm this problem with the non-OSE 2.1.4 on Intrepid. I just upgraded my system from Hardy a few days ago. Imagine my shock when I fire up s VM, walk away for a few hours and come back to find that all of my 2GB of ram and about 1GB of swap space have been eaten by a 512MB virtual machine running Windows XP. I repeated the experiment, eliminating all of the other potential memory-hog applications. Running just X with Virtual Box, the system grinds to a halt in around 2 hrs.

If you need a verbose log, let me know and I'll generate one. The bad part about this is that I use vbox as a development tool. Being unstable greatly limits what I can do.

comment:3 Changed 9 years ago by arkainrdk

One other thing I forgot to mention. If you catch vbox before it completely devours your memory and try to shut it down, it goes zombie instead. This not only locks away all memory it claimed, but also prevents a normal system shutdown.

comment:4 Changed 9 years ago by frank

arkainrdk, please attach your VBox.log file for a VM session. It is not necessary that this session goes out of memory, but I would like to know your exact configuration. Therefore starting such a VM session, properly shutting does this session and attaching the VBox.log file to this ticket would be sufficient.

comment:5 Changed 9 years ago by frank

And, from your comment the problem apparently started when you upgraded your Ubuntu host from Hardy to Intrepid. Was VBox upgraded as well? Did you change any setting or can you confirm that VBox worked without any memory with the exact same settings on the distribution?

Changed 9 years ago by arkainrdk

Log file generated just minutes ago.

comment:6 Changed 9 years ago by arkainrdk

For the log file I just attached, I booted into Windows XP, ran notepad, then shut down the system. I did this just moments ago. The VirtualBox process representing the running VM session went Zombie instead of closing out. Even though PS doesn't show it, the memory allocated by VirtualBox is still allocated AND GROWING!!! I believe I was using 2.1.4 on Hardy. I had no problems on Hardy. As such, I am beginning to think this may be a kernel issue. The session being used is the same as the one I began with on Hardy. After discovering the problem to be VirtualBox related, I did try turning off PAE extensions. No effect. A zombie process can normally be removed if the parent is sent a SIGCHLD message, or if the parent is killed and init calls wait(). Unfortunately, neither of these approaches work when trying to remove the VirtualBox zombie.

comment:7 Changed 9 years ago by arkainrdk


It appears that there is a leak somewhere within the kernel itself. How fast it leaks depends on how large a chunk software happens to be allocating from the system. Since VBox allocates the largest chunk of all the programs that I run, that's where I first noticed the problem. However, running other software, then leaving my system running overnight, I came back to a similarly over-allocated system. It just took a lot longer. It would appear that all memory-leak issues on Ubuntu Intrepid for amd64 should first be investigated as a kernel bug.

comment:8 Changed 9 years ago by frank

Interesting. I'm running Intrepid/AMD64 myself. Are you running any special kernel driver, for instance an AMD fglrx kernel module or something like that?

comment:9 Changed 9 years ago by arkainrdk

The only 3rd party drivers in my system are the NVidia driver (177.82) and the MousePen driver for my Genius 8060 tablet. Other than that, all drivers are standard. The problem is probably specific to the 2.6.27 kernel. I'm using the 2.6.24 kernel from Hardy right now, and I'm not having any problems.

comment:10 Changed 9 years ago by arkainrdk

Side note, I was having the problems even before installnig the MousePen driver, so that one doesn't factor in...

comment:11 Changed 9 years ago by frank

And the nVidia kernel module -- are you using the same version on both kernels?

comment:12 Changed 9 years ago by arkainrdk

Yes. Exactly the same version.

comment:13 Changed 9 years ago by arkainrdk

If I had to hazard a guess, I'd say the memory leak is a matter of kernel memory allocations since the resulting blocks do not show up in the memory block list for any process active or otherwise. Not to mention that the allocations keep occuring even after VBox has been zombied.

comment:14 Changed 7 years ago by frank

  • Status changed from new to closed
  • Resolution set to fixed

Please reopen if still relevant with VBox 4.1.6.

Note: See TracTickets for help on using tickets.
ContactPrivacy policyTerms of Use