On 13.10.2016 18:04, Martin Kletzander wrote:
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.
Yes, couple of drivers were switched to server side drivers because of some licensing nonsense.
However it doesn't use virStateDriver.
That's because vbox is stateless driver. Just like esx for instance. Michal