Re: [libvirt] [PATCH 3/4] vbox: change API (un)initialization logic.

On Wed, Oct 12, 2016 at 04:00:52PM -0400, Dawid Zamirski wrote: > On Tue, 2016-10-11 at 10:58 -0400, Dawid Zamirski wrote: >> On Tue, 2016-10-11 at 16:22 +0200, Martin Kletzander wrote: >> > On Wed, Sep 28, 2016 at 01:41:35PM -0400, Dawid Zamirski wrote: >> > >> > The allocation is not guarded by any lock, so there's still a >> > race. I >> > think there should be a global struct that has only some lock in it >> > and >> > whatever global data you need, the struct will be initialized on >> > the >> > first call to any function (check out VIR_ONCE_GLOBAL_INIT) and >> > then >> > the >> > connection (or global data or how it's called) would be reference >> > counted (just like you have). It's just that having the reference >> > count >> > in the object you will be reallocating over and over again for each >> > connection is not really good. >> > >> >> >> Thanks, I see, I'll address this in v2 >> > > So after my initial attempts at handling this as suggested (create > vboxDriver struct and initialize in VIR_ONCE_GLOBAL_INIT), I've > stumbled upon virStateDriver structs used in other drivers that > apparently has .stateInitialize, .stateCleanup that to me look like > perfect places to call vbox's pfnComInitialize pfnComUnintialize pairs. > Would this be a good idea to utilize the virStateDriver for this or > should I stick with VIR_ONCE_GLOBAL_INIT way? > I just now realized you said the issue we are talking about crashes the libvirt daemon, right? And it does not use virStateDriver? That's weird. You are connecting to vbox:///session, but the crash happens in the libvirt daemon. That means we switched the vbox driver to the daemo-side driver, so I'd expect it to be stateful driver.

However it doesn't use virStateDriver.