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 -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list