On 03/12/2013 06:15 PM, Viktor Mihajlovski wrote:
At the same time the event loop will call remoteClientCloseFunc
which waits for the mutex while the connection is unrefed.
It will obtain the (now invalid but non-error checking) mutex,
copy the closeCallback pointer (shorty before the connection object is
destroyed) and will die upon trying to call closeFreeCallback (NULL
by now).
Minor correction: the closeFreeCallback was NULL from the beginning
but that was actually a blessing, because it indirectly helped
to uncover this race.
One thought would be to increase the refcount of the connection
object in remoteClientCloseFunc before calling the closeCallback.
Increasing the refcount there is too late. I have experimentally
increased the refcount before registering remoteClientCloseFunc
and decreased it on deregistering, but that leads to the dreaded
virsh "leaked reference(s)" message because virConnectClose is always
the first to happen.
My next attempt would be to reset the closeCallback in virConnectDispose
but I need to sleep over it first :-).
--
Mit freundlichen Grüßen/Kind Regards
Viktor Mihajlovski
IBM Deutschland Research & Development GmbH
Vorsitzender des Aufsichtsrats: Martina Köderitz
Geschäftsführung: Dirk Wittkopp
Sitz der Gesellschaft: Böblingen
Registergericht: Amtsgericht Stuttgart, HRB 243294