memory leak in VBoxService.exe

[maxchen]

the VBoxService.exe in guest os seems to leak mem 1MB every 2 hours in headless mode. Note that if the VM is not running in headless mode, VBoxService.exe is OK, around 2.7M all the time.

version 4.1.22 host: Windows7 x64, and Ubuntu 10.04 x64 guest: windows xp with VB addition ver 4.1.22, running in headless

[maxchen]

tasklist in the guest, memory of VBoxService.exe

08:58 2012-09-17 23860

14:58 2012-09-17 26452

20:12 2012-09-17 28708

08:09 2012-09-18 33868

20:12 2012-09-18 39072

20:25 2012-09-20 59876

[Frank Mehnert]

Not able to reproduce. WinXP guest here with 4.1.22 Additions. VBoxService memory consumption stays rock solid at 3228K according to the task manager.

[maxchen]

do you run the VM in headless mode? If run in GUI mode (VB interface), the memory stays constant.

[Frank Mehnert]

Yes, I run that VM with VBoxHeadless.

Could you do a bit more debugging? In the guest, please open regedit.exeand add/edit the following keys:

HKLM\SYSTEM\CurrentControlSet\Services\VBoxService\ImagePath = "system32\VBoxService.exe -vvvv --logfile c:\VBoxService.log" (REG_EXPAND_SZ)

After the registry modification were made the guest needs to be restarted. Please then attach the VBoxService.log file(s) (will be written to C:\ on the guest) to this defect. Thanks!

[maxchen]

one of the VM, the VBoxService use 148076kB now.

But another VM (cloned), the java is updated to 7u7, the mem consume by VBoxService is interesting, it is cycling, say (I log them manually)

15:16 2012-09-17	5368
20:31 2012-09-18	8692
07:27 2012-09-19	13424
19:09 2012-09-19	18464
20:25 2012-09-20	25680
08:12 2012-09-22	11836
10:24 2012-09-23	23144
09:18 2012-09-27	27064
09:46 2012-09-28	6720
09:12 2012-09-29	14072

[maxchen]

seems this also exist in 4.2.6

C:\>systeminfo | find "Time:"
System Up Time:            4 Days, 7 Hours, 36 Minutes, 11 Seconds

C:\>tasklist
Image Name                   PID Session Name     Session#    Mem Usage
========================= ====== ================ ======== ============
System Idle Process            0 RDP-Tcp#17              0         28 K
System                         4 RDP-Tcp#17              0         92 K
smss.exe                     276 RDP-Tcp#17              0        244 K
csrss.exe                    400 RDP-Tcp#17              0     14,548 K
winlogon.exe                 424 RDP-Tcp#17              0      3,372 K
services.exe                 468 RDP-Tcp#17              0      1,524 K
lsass.exe                    480 RDP-Tcp#17              0      2,468 K
VBoxService.exe              640 RDP-Tcp#17              0     53,964 K

[Frank Mehnert]

We fixed a potential memory leak. Would you willing to try a test build? If so, please install the additions from ​this iso image. Thank you!

[Frank Mehnert]

Fixed in VBox 4.2.8.

[maxchen]

Dear all, It seems that the memory leaks much faster! in 4.2.8, 1MB per hour, in old version, only less than a half of it. Sorry that the release of 4.2.8 is during the Chinese New Year. I am not able to test it out. but I will provide a vm that you can RDP connect, please leave me a message, I will send you the IP and u/p. Thanks again.

[Alex]

Unable to reproduce with 4.2.8 version (4.2.8 guest additions). Maybe I should start some specific application in the guest to reproduce this?

Can you attach new VBoxService.log from 4.2.8 version please?

[Frank Mehnert]

Any news here? We don't have reports from other users regarding such a memory leak.

[maxchen]

ver 4.2.16 log file

[maxchen]

Replying to frank:

Any news here? We don't have reports from other users regarding such a memory leak.

seems it is still leaking. Ver 4.2.16, attached is the log file

[adam]

Replying to maxchen:

Replying to frank:

Any news here? We don't have reports from other users regarding such a memory leak.

seems it is still leaking. Ver 4.2.16, attached is the log file

Yes, I am getting this on a W2000 Guest, have reported it at ticket #12072 . You may want to follow there

[pentagonik]

Please note that the initial fix only is available in the next upcoming 4.2 maintenance version. 4.2.18 does *not* include the fix.