#2131 closed defect (worksforme)
Memory leak during Linux installs?
Reported by: | A20_user | Owned by: | |
---|---|---|---|
Component: | VMM | Version: | VirtualBox 2.0.0 |
Keywords: | Memory leak | Cc: | |
Guest type: | Linux | Host type: | Windows |
Description
Host is Vista Home Premium with all patches, but no SP1.
Created a fresh 8 GByte *.vdi from VBoxAdmin. Created a new machine for "openSUSE", 512 MByte RAM, 8 MByte VGA, enabled access to Host DVD drive including pass thru, enabled audio using "Windows" driver. Booted from PC-Welt Linux DVD 4/2008 containing OpenSuse 11 and other, booted OpenSuse in 800x600 for install. Physical memory usage indicated by Task Manager rose at one point near start of install by a few 100 MByte, but still not too dangerous, approx 1.3 GByte in use then, 0.5 GByte before start of virtual machine. Choose some more software packages during install, in my case some fileservers and command and kernel development. Installation runs, the V.B. window ist partially covered most of the time, I have only occassionally a look on it, click into, go back by Ctrl (host key). Installation seems complete, Guest reboots, Physical memory usage increases sharply to 1.62 GByte. But even TopToBottomNT process monitor shows only "Process total address space is 700328 K" for the VirtualBox.exe actually running the Guest (the other with GUI is still there, but neither it nor the VBoxServ.exe has dramatic memory usage). I manually counted the 1024 Kb allocations and it were only approx 500, very few larger ones (up to 8 Mb) between them in the list. But all the memory freed after shutting down Guest (clean power down from within it, after it booted from its *.vdi). I tried the same install a second time and got the same result again. Of course I did not exactly the same in parallel on that computer, but nearly the same, little *.pdf reading and web browsing. Checked all the svchost.exe for excessive total address space, but none.
This time I will not boot into just installed Linux, but start Rescue Live-CD from this menu, and then mem test. (My mem is ok, but just as a machine stress.)
Task Manager dump of this VirtualBox.exe is 650 MByte only.
I shortly started another Live-CD inside the DVD and (seen later) probaly at same time mem usage increased again by apporx 200 to 300 MByte, but returned to 1.62 G after return to primary boot menu.
Ok, power off. Physical mem usage down to 791 MByte, there is still something missing, at first time it went down to 500.
Is it Vista or VirtualBox?
The *.log and *.xml are attached.
Attachments (1)
Change History (10)
by , 16 years ago
Attachment: | test2_SuSE11_VB.zip added |
---|
comment:1 by , 16 years ago
Resolution: | → invalid |
---|---|
Status: | new → closed |
It's Vista. It will keep a lot of files in its cache. If VBox were leaking hundreds of MBs, you'd quickly run out of memory after starting and stopping some VMs.
comment:2 by , 16 years ago
Resolution: | invalid |
---|---|
Status: | closed → reopened |
I am sorry to reopen it. Your answer is wrong. I never said VBox leaks always memory, but only under these very specific conditions! The left bar in this Task Manager view, in German system titled "Arbeitsspeicher", shows what is really used and cannot be freed. Vista's excessive caches are freed if memory is needed and do not account to the magnitude of this bar, at least not directly. Both statements "as far as I observed in the past".
comment:3 by , 16 years ago
It can be observed that memory usage increases sharply by approx 200 to 400 MByte while a 7 GByte sized partition inside a sparse *.vdi is formatted to ext3 file system using under Linux, regardless whether this is a fresh (empty) *.vdi or it has already been filled. The ext3 formatter does not write the whole space, but only some spots inside.
During installation more and more is copied to this *.vdi and memory usage nearly constantly increases, there are only minor reductions in the rise path. I could duplicate the process by giving a "cp -R /usr /uuu" command.
The memory used in this way is definitely not available for other applications. This is extremly bad, because a virtual machine with only 400 or 512 MByte of RAM assigned increases its RAM usage up to 1 GByte. This memory is freed when the v.m. terminates.
A Windows XP SP3 client inside a *.vmdk disk image shows the same behavior when copying C:\Windows into a fresh directory C:\x. Memory usage rises. I aborted copy after a few 100 MByte. I truly deleted the copy by Shift+Backspace, that means it was not moved into Trash. I repeated the copy process and Host memory usage rose again. This is strange because the same sectors inside the *.vdi should be re-used for the new copy (as I have observed on real XP machines), and even if Host Vista has a sector cache, then the same sectors should be touched again, so there is no need to allocate more and more memory. I repeated the process multiple times and memory usage increased more and more. In the end, when I shut down the Guest (having 400 MByte RAM assigned), more than 1 GByte of Host memory was freed.
I cannot exclude that the root cause is a fault of Vista, but I know for sure that VirtualBox 2.0.0 as it currently behaves under Vista cannot be called "stable".
I made the same copy test using VMware Player 2.0.4, a sparse and growing *.vmdk disk image, same Win XP SP3 Guest. The memory usage of Host was constant, no increase. That means it can be done better.
Now Win XP SP3 host and a W2000 guest inside *.vmdk (FAT32, not NTFS like all others). The problem seemed to be less in this setup, but available memory was decreasing. But: Task Manager has different graphical display. Instead of Physical Mem you get Pagefile usage, Physical Mem is only a number, and not reported as used, but as available.
comment:4 by , 16 years ago
priority: | critical → major |
---|
As I said before. If you repeat the process and there was indeed a memory leak, then you would run out of memory very fast.
It might have something to do with the index service in Vista. There's a way to exclude files from being indexed and I believe we don't use that yet for vdi files.
comment:5 by , 16 years ago
Did I not just wrote in my last post that I did repeat the copy operations and indeed more and more memory has been allocated? I just had no fun to repeat it any longer, but may try so if it helps you. But currently I do not see whether 400 or 900 MByte of occupied memory make a difference.
The search indexer is completely disabled here, so this cannot cause the problem.
comment:6 by , 16 years ago
A20_user, did you enable VT-x/AMD-V for that VM session? If not, could you check if that makes any difference?
comment:7 by , 16 years ago
VT-x was disabled during all tests. I enabled it, tested again, no difference. I prepared another lengthy report, but ... it looks like the Intel graphics driver was the memory hog. I installed a newer version (same major, minor and patch number, but later build and GUI is a bit different) and at least one strange effect I just observed during the latest tests is cured: Scrubbing with another window over the Task Manager increased memory usage (and this mem was not freed on Task Manager close).
I'm very sorry if I hit the wrong candidate - I still have to do final verification - but as a side effect I found another problem which must be inside VirtualBox this time.
comment:9 by , 16 years ago
Resolution: | → worksforme |
---|---|
Status: | reopened → closed |
*.log and both *.xml