Opened 13 years ago
Closed 10 years ago
#9068 closed defect (fixed)
Guest Memory leak when using "guestcontrol execute" => Fixed in SVN
Reported by: | goesen | Owned by: | |
---|---|---|---|
Component: | guest control | Version: | VirtualBox 4.0.8 |
Keywords: | Cc: | ||
Guest type: | Linux | Host type: | Linux |
Description (last modified by )
64 bit linux host 32 bit linux guest Virtualbox 4.08
on host running: while [ true ]; do VBoxManage --nologo guestcontrol execute $MACHINE --username $USER /bin/ls; done
in guest system memory allocation of VboxService is skyrocketing!
Attachments (2)
Change History (12)
comment:1 by , 13 years ago
Summary: | Guest Memory leak when using "guestcontrol execute" → Guest Memory leak when using "guestcontrol execute" => Fixed in SVN |
---|
comment:2 by , 13 years ago
Resolution: | → fixed |
---|---|
Status: | new → closed |
Should be fixed in VBox 4.0.10, please update your Guest Additions.
comment:3 by , 13 years ago
Resolution: | fixed |
---|---|
Status: | closed → reopened |
Sry, but nothing has changed at all.
I updated my Guest Additions and my Host service. Checked VBoxManage,VBoxServive and kernel modules
Everything is on 4.0.10 r72479. And still rapid execution of commands like posted above will make VBoxService allocate memory until it gives up. Message on host:
VBoxManage: error: Process could not be started: VERR_NO_MEMORY.
and after a few dozens of that comes the final deadblow VBoxManage: error: Invalid user/password credentials.
follow-up: 5 comment:4 by , 13 years ago
Well, there was definitely a bug which was fixed. The command line you posted would not work because it does not contain a password. In that case, some memory was leaked. But there might be other code pathes leaking memory as well.
comment:5 by , 13 years ago
Replying to frank:
Well, there was definitely a bug which was fixed. The command line you posted would not work because it does not contain a password. In that case, some memory was leaked. But there might be other code pathes leaking memory as well.
Well in Version 4.0.10 both the command
while [ true ]; do VBoxManage --nologo guestcontrol execute $MACHINE --username $USER --password $PASSWORD /bin/ls; done
as well as the command
while [ true ]; do VBoxManage --nologo guestcontrol execute $MACHINE --username $USER /bin/ls; done
is leaking memory. So i don't think this bug should be considered fixed
comment:6 by , 13 years ago
Seems like that memory leak is caused by the guestadditions reading stdout, and not deallocating memory after doing so. Just execute /usr/bin/yes-> memory get's exhausted in a few seconds
comment:7 by , 13 years ago
@goesen: Thanks for the report. For 4.1.2 we've implemented a guest process policy by serving up to 5 processes at once. This limit can be increased/decreased or even deactivated if needed then.
comment:8 by , 13 years ago
Component: | other → guest control |
---|
by , 11 years ago
Attachment: | ps_and_times.log added |
---|
Output of "ps aux" for each invocation of "guestcontrol execute"
by , 11 years ago
comment:9 by , 11 years ago
I still have this kind of problem with 4.3.6, host: Debian Wheezy 64 bits, guest: Windows Server 2008 64 bits.
When executing the following script on host:
while [ 1 ]; do vboxmanage guestcontrol win2k8-newvbox execute "C:\Windows\System32\ping.exe" --username Administrator --password "some_password" --verbose --wait-stdout --wait-stderr --wait-exit -- "-n" "20" "1.1.1.1" >>vbox_exec.log ps aux >>vbox_exec.log done
I can see the virtualbox process memory consumption rise to several GB.
Please find attached a VBox.log file, and a regular output of 'ps aux' (once between each invocation of 'guestcontrol execute').
If you need any further information, I will do my best to provide you with it. If you prefer me to open a new ticket for this problem, please let me know and I will do so.
Thanks.
comment:10 by , 10 years ago
Description: | modified (diff) |
---|---|
Resolution: | → fixed |
Status: | reopened → closed |
Please reopen if still relevant with VBox 4.3.20. The memory leak we fixed in VBox 4.3.18 could be the same you observed.
Thanks for the report, will be fixed in the next maintenance release.