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 v2So 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. I'm Cc'ing Michal to let him look at it as he's more handy in the whole vbox area.
PS. Thanks a lot for reviewing my code and guiding me through it all.
signature.asc
Description: Digital signature
-- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
