VBoxSVC process crash (6.0 beta1)

[mhanor]

It seems a crash is reproducible by having the Ext. pack already installed. Starting VirtualBox Manager, followed by uninstalling the Ext. pack from the Preferences menu, then closing the Manager, a VBoxSVC process crash will occur. Following the crash, the VBoxSDS service must be restarted, otherwise all launches will fail with RPC_S_SERVER_UNAVAILABLE.

Host: Windows 10 1803 64 bit

[socratis]

Confirmed on OSX. Interesting, a cross platform crash in VBoxSVC, that's a rare one!

Host: OSX 10.11.6
VirtualBox: 6.0.0_BETA1 r126216 (Qt5.6.3)
ExtPack: 6.0.0_BETA1 r126212

[mhanor]

The crash occurs with 6.0 Beta 2 also.

[klaus]

Congrats for finding the biggest todo related to the new "cloud provider in extpack" feature. It currently lacks handling the extpack install and uninstall cases "at VBoxSVC runtime". The first is less serious (it means that cloud providers show up only after a VBoxSVC restart), the second crashes because the library is unmapped without removing the cloud provider, ending up as a crash when trying to execute code which isn't there any more.

[klaus]

Should be fixed now with the latest dev snapshot builds... now extpack install/uninstall/upgrade should be all trouble free, including instantly picking up new cloud providers (which previously needed a VBoxSVC restart).

[mhanor]

With VirtualBox-6.0.0_BETA2-126867-Win, it won't let me uninstall the ext. pack.

Code: Select all

Uninstall extension pack 'Oracle VM VirtualBox Extension Pack' failed because at least one Cloud Provider is still busy.
Result Code: 
E_FAIL (0x80004005)
Component: 
ExtPackManagerWrap
Interface: 
IExtPackManager {edba9d10-45d8-b440-1712-46ac0c9bc4c5}

[klaus]

I'll retry my testing with the extpack from the beta2. Seems something isn't quite compatible (or you did something wrong with updating the base package, which isn't likely). In the end the "cloud provider is busy" check is somehow not working.

[mhanor]

I usually uninstall the existing ext pack, before installing a new version. I haven't tried to see if an upgrade process is possible without uninstalling the old version of ext pack.

[klaus]

Reproduced. Will work on it next week.

[klaus]

If you use the latest dev test builds (r126929 or later) then you can uninstall the extpack again after upgrading the base package. The remaining bug was that the cloud provider in the old extpack wasn't detected as not implementing the current API and this made some newly added sanity checks go wrong.

Strictly speaking there is no requirement to uninstall the extpack before upgrading the base package (and with the betas until that very recent build the extpack uninstall will simply not work right). If there's an old extpack with a new base package it will be reliably flagged as unusable (the times where this wasn't quite perfect are extremely limited). That said - after upgrading the base package to the dev build you can go back to your habit. It's not necessary to always uninstall the old extpack first, but it's not wrong as such either.

[mhanor]

I tried to do an upgrade without manual uninstall, but it couldn't, it gave me a similar error message, about the cloud provider.

[klaus]

Is there a misunderstanding or am I testing the wrong thing now (I did fix a bug, but it could be that there's another left in some odd corner case)? You need to update the base package first to the latest test build. That will keep the extpack, but will have the side effect that the cloud provider will disappear (because it is incompatible with the latest base package). Then you can remove or upgrade the extpack to the latest, too. Then the cloud provider will re-appear but shouldn't block uninstalls.

If you provide VBoxSVC.log it should be possible to hunt down the remaining issues...

[mhanor]

You fixed it. I just upgraded from ext pack 126642 to 126930 (without manual uninstalling the old ext pack), using VirtualBox-6.0.0_BETA2-126930-Win. In my previous post, I was saying that upgrading the ext pack from 126642 to 126868 (without manual uninstalling the the old ext pack), using VirtualBox-6.0.0_BETA2-126867-Win, wasn't possible because it returned a similar error to the error that appeared when just uninstalling the existing ext pack.

Btw, perhaps you are not aware, but double-clicking the .vbox-extpack file (e.g. to install it), when VirtualBox launches, it first displays this error message: Unknown option <full path of the vbox-extpack file>, where <full path of the vbox-extpack file> is the actual path of the ext-pack file.