VB 4.1.8 Huge Memory Leak on win7 64 bits?

[Providence SALUMU]

After last upgrade from 4.1.6 to 4.1.8, vb now stops working suddenly after about 2hours on win7.

To reproduce:

• Run a linux OS (gentoo) on a 4.1.8 vb's guest
• Monitor how memory is being increased
• Reboot the linux client from inside the guest, without switching off the guest machine

-Monitor how memory is never released

At some point in the time, the guest takes up to 4Go in RAM when it freezes!

[Providence SALUMU]

Before switching off the guest, more than 6Go in RAM occupied

[Providence SALUMU]

Guest process memory

[Providence SALUMU]

After killing vb guest, memory consumption lowers again

[Providence SALUMU]

VBox.log

[Frank Mehnert]

I don't see the problem. You configured the guest to use 4GB RAM. So if this is too much, why not just decrease this value? Note that the guest will not catch the whole memory at once, only when it is actually needed.

[Providence SALUMU]

Thanks for your answer, Frank. Inlined are a few comments...

Replying to frank:

I don't see the problem. You configured the guest to use 4GB RAM. So if this is too much, why not just decrease this value?

This has never been a problem before I upgraded to 4.1.8. My linux guest hasn't never consumed up to 4GB (No PAE extensions enabled) before I upgraded VB. When booting the linux guest it only takes 175Mib RAM and hardly goes up to 1.75GiB (Eclipse + Chromium running)

AFAIK, with no PAE into linux kernel, most of the processes end up killed by the kernel once they reach ~3.5GiB of RAM. Correct me if I'm wrong, idle processes are likely to be on the swap disk!

Note that the guest will not catch the whole memory at once, only when it is actually needed.

Assuming you are right, why then when I restart my linux guest inside the VM (without restarting the whole VM itself, I insist), the guest VM still needs the whole of the previous 4GiB RAM? Shouldn't it just release it because the linux kernel has reboot and released the RAM?

[Providence SALUMU]

Again Frank, I just ran into another scenario as described below:

1- I boot up the linux guest, it was taking 175Mb RAM. My win7 host shows 3.05Gb RAM taken at that time. 2- From inside the VM, I launched chromium, monitored the RAM from inside the linux guest, it raised up to 835Mb (I assume that Chromium ate up 660Mb). Monitoring the RAM from the win7 task manager shows that the RAM consumption goes up to 4.00Go (~950Mb eaten up by chromium being launched inside the guest). 3- Killed chromium from inside the linux guest, monitored the RAM consumption from inside the guest, it went back to 223Mb RAM occupied. But monitoring the RAM from win7 task manager, it stays up to 4.00Gb.

To me, the VM should just realese that RAM not in use by the guest.

I haven't run the same scenario using VB 4.1.6, but will do it pretty soon and let you know of my findings.

[Providence SALUMU]

Again Frank, I just ran into another scenario as described below:

I boot up the linux guest, it was taking 175Mb RAM. My win7 host shows 3.05Gb RAM taken at that time.

From inside the VM, I launched chromium, monitored the RAM from inside the linux guest, it raised up to 835Mb (I assume that Chromium ate up 660Mb). Monitoring the RAM from the win7 task manager shows that the RAM consumption goes up to 4.00Go (~950Mb eaten up by chromium being launched inside the guest).

Killed chromium from inside the linux guest, monitored the RAM consumption from inside the guest, it went back to 223Mb RAM occupied. But monitoring the RAM from win7 task manager, it stays up to 4.00Gb.

To me, the VM should just realese that RAM not in use by the guest.

I haven't run the same scenario using VB 4.1.6, but will do it pretty soon and let you know of my findings.

[Frank Mehnert]

Automatically releasing the memory not used by the guest is not possible. The VMM has no idea if the guest RAM is used or not. As soon as the guest touches a guest memory, the host will assign the proper amount of memory to the guest. There are two techniques possible to reclaim memory from the guest:

1. Memory ballooning: A guest process occupies memory from the guest and tells the VMM that it can reuse this memory. This is already possible.
2. Memory hotplugging: The VMM unplugs memory from the guest, this requires support from the guest OS. Linux is capable of hotplugging but the kernel config option is disabled on most distributions. Windows Server 2008 is able to do this as well. But VirtualBox does not implement memory hotplugging at the moment.

You say that you did not observe this behavior before upgrading to VBox 4.1.8. My guess is that you did not only update VirtualBox but also installed some additional components into the guest or upgraded some guest packages.

Again, I don't think this is a VirtualBox bug for the reasons I sketched above.

[Providence SALUMU]

Replying to frank:

Automatically releasing the memory not used by the guest is not possible. The VMM has no idea if the guest RAM is used or not. As soon as the guest touches a guest memory, the host will assign the proper amount of memory to the guest. There are two techniques possible to reclaim memory from the guest:

1. Memory ballooning: A guest process occupies memory from the guest and tells the VMM that it can reuse this memory. This is already possible.
2. Memory hotplugging: The VMM unplugs memory from the guest, this requires support from the guest OS. Linux is capable of hotplugging but the kernel config option is disabled on most distributions. Windows Server 2008 is able to do this as well. But VirtualBox does not implement memory hotplugging at the moment.

You say that you did not observe this behavior before upgrading to VBox 4.1.8. My guess is that you did not only update VirtualBox but also installed some additional components into the guest or upgraded some guest packages.

Again, I don't think this is a VirtualBox bug for the reasons I sketched above.

You're Frank, I built a new linux kernel using the same .config file as before indeed. I also installed a whole new bunch of packages on top of that! I agree to say that it might not be a VirtualBox bug indeed, and I will investigate a bit more on what had been changed after I had upgraded VirtualBox.

Would you be kind enough and close this ticket so that others don't get confused by its title please? Thanks a lot for your explanations!!!

[Frank Mehnert]

Thanks for the feedback!