Fail to contact COM server => Fixed in SVN

[efayol]

I'm using Ubuntu 20.04.4 on x86_64 with Gnome on X11. Since I've updated to 6.1.36, I cannot use any vbox command nor the VirtualBox VM Manager GUI: they stall a few minute then end with an error about COM.

• The VirtualBox GUI displays an error dialog with the following message: "

Failed to acquire the VirtualBox COM object.

The application will now terminate.

Callee RC: NS_ERROR_ABORT (0x80004004) "

• Command "VBoxManage list vms" sends the following to stderr:

VBoxManage: error: Failed to create the VirtualBox object! VBoxManage: error: Code NS_ERROR_ABORT (0x80004004) - Operation aborted (extended info not available) VBoxManage: error: Most likely, the VirtualBox COM server is not running or failed to start.

Reinstalling Virtualbox 6.1.34, it is working fine again.

[galitsyn]

Hi efayol,

Which package (6.1.36) did you install which does not work for you? Is there a chance that somehow you have installed VirtualBox package provided by Ubuntu in parallel? Or maybe you have installed one of the "Development snapshots" from https://www.virtualbox.org/wiki/Testbuilds?

[efayol]

I installed virtualbox-6.1_6.1.36-152435_Ubuntu_focal_amd64.deb from www.virtualbox.org/wiki/Linux_Downloads page. I have no other virtualbox package installed. virtualbox-6.1_6.1.34-150636.1_Ubuntu_eoan_amd64.deb is working fine.

[galitsyn]

Could you please attach $HOME/.config/VirtualBox/VBoxSVC.log (after you attempted to run "VBoxManage list vms" with 6.1.36)? I do not see the issue w/ 6.1.36 .deb and Ubuntu 20.04.4 host on my end by the way.

[galitsyn]

And also, what is the output of "ps -AF | grep -i vbox" right after you executed VBoxManage?

[efayol]

$ ps -AF | grep -i vbox
root       55377       2  0     0     0   0 18:03 ?        00:00:00 [iprt-VBoxWQueue]
root       55378       2  0     0     0   1 18:03 ?        00:00:00 [iprt-VBoxTscThr]
eric       55914   28894  0  3523  2464  10 18:08 pts/1    00:00:00 grep --color=auto -i vbox

I have many more VMs than the four is listed in the log file (see attachement). Looking at the pre-installation log file, the next VM in log should have been this one:

00:00:00.287344 nspr-2   Loading settings file "/home/eric/VirtualBox VMs/Squeeze32/Squeeze32.vbox" with version "1.12-linux"

[galitsyn]

efayol,

do you see any difference if you install ​https://download.virtualbox.org/virtualbox/6.1.36/virtualbox-6.1_6.1.36-152435~Ubuntu~eoan_amd64.deb (Ubuntu 19.10 / 20.10 / 21.04 version from Linux Downloads page) ?

[efayol]

No, exactly the same behavior

[galitsyn]

Still cannot reproduce it here. Could you please attach strace_vboxmanage.txt from:

strace -f VBoxManage list vms 2> strace_vboxmanage.txt

[efayol]

The file is too big to attach, even gziped. Please use this link to retrieve it: ​https://drive.google.com/file/d/1ah3iDdkinMtTY2_mkTevbrPoN3wzlF0L/view?usp=sharing

[galitsyn]

Hi efayol,

Thank you for the log. I am currently looking at it. I noticed that the host is using French localization. Do you observe any difference if you run:

LANG=en_US.UTF-8 LC_ALL=en_US.UTF-8 VBoxMange list vms

Also, could you please attach "/home/eric/VirtualBox VMs/VM4/VM4.vbox"?

[efayol]

Same result. I also tried LANG=C with the same effect.

[galitsyn]

Thank you for the VM config. I think I reproduced the issue. It looks specific to VM4.vbox content. Will get back to you once it is fixed.

[galitsyn]

Hi efayol,

Your VM config is corrupted (will need to investigate why). The way to fix it could be to edit VM4.vbox manually and change "screens" value to something reasonable (say, "1"):

<VideoCapture enabled="false" screens="18446744073709551615" horzRes="1024" vertRes="768" rate="512" fps="25" maxTime="0" maxSize="0"/>

Note, there are multiple "VideoCapture" sections in config, all of them need to be updated. Also check other VMs. This is of course a workaround, but it can let you go until this case will be handled in the next VBox release.

[pentagonik]

We found and fixed the bug -- we'll provide a test build soon, plus it will be included in the next upcoming maintenance release.

[fth0]

Hi galitsyn,

wouldn't it be easier for the users to simply remove the VideoCapture sections as long as enabled=="false"? Or do you expect further problems with that strategy?

[efayol]

Hi galitsyn,

Thank you for the workaround, it worked!

By the way, I had 3 other VMs with the same values in their vbox file. One happens to be a clone of a VM, I've not started in a while, that have no screens attribute at all in its VideoCapture tags. I suppose some version of Virtualbox have added that screen attribute when I've run these four VMs, erroneously initializing it with this value which is (2⁶⁴)-1.

6.1.34 and older versions were fine with it though...

[galitsyn]

Replying to fth0:

Hi galitsyn,

wouldn't it be easier for the users to simply remove the VideoCapture sections as long as enabled=="false"? Or do you expect further problems with that strategy?

I would go for minimal change here (change to screens="1") because modifying VM's xml file is the very last thing to do and it is strongly not recommended (might have negative impact). But in this case, I do not see the other way to workaround problem.

[pentagonik]

There is a new 6.1 test build available here which should fix the issues.

Please let me know if this works for you now. Thanks!

[galitsyn]

The issue should be fixed in VirtualBox 6.1.38. Please refer to https://www.virtualbox.org/wiki/Downloads.