On Wed, 2016-11-23 at 08:55 -0500, John Ferlan wrote:
[...]
+ +static vboxDriverPtr +vboxGetDriverConnection(void) +{ + virMutexLock(&vbox_driver_lock); + + if (vbox_driver) { + virObjectRef(vbox_driver); + } else { + vbox_driver = vboxDriverObjNew(); + + if (!vbox_driver) { + virReportError(VIR_ERR_INTERNAL_ERROR, "%s", + _("Failed to create vbox driver object.")); + return NULL; + } + } + + if (vboxSdkInitialize() < 0 || vboxExtractVersion() < 0) {
In this path should vboxSdkUninitialize be called (since it wouldn't be called in the destroy path)?
If vboxSdkUnintialize fails, VBoxSVC is not started so it does not need to be unintialized - which is in line with the sample code included SDK where it returns with EXIT_FAILUE in main if pfnClientInifialize fails. However, if vboxExtractVersion fails (unlikely) we might want to call gVBoxAPI.UPFN.Unintialize(vbox_driver) directly (not via vboxSdkUninitialize as it checks connectionCount > 0 which on failure would be 0). I've just tested both cases with gVBoxAPI.UPFN.Unintialize in the failure path, and calling it does not do any harm in both cases, so I guess it would be a good idea to put it there.
I can make the adjustment before push, but figured I'd ask.
Regards, Dawid