https://bugzilla.redhat.com/show_bug.cgi?id=866524 The two patches are to fix the same bug in different method, 1/2 is suggested by Daniel in the bug. 2/2 is an alternative way to fix it by locking the whole virConnect object. The reason to post 2/2 is that I think 1/2 doesn't fix the root problem, though I believe it must fix the bug. A thread can get the lock before/during doRemoteClose, and it might drop into the similar situation, though it's not the case now because remoteClientCloseFunc doesn't do changes which can cause race for the later doRemoteClose. However, I'm not sure if locking the whole object will cause some unexpected result. Osier Yang (2): remote: Avoid the thread race condition Lock the whole virConnect Object when disposing to avoid the thread race src/datatypes.c | 4 ++-- src/remote/remote_driver.c | 4 ++++ 2 files changed, 6 insertions(+), 2 deletions(-) Regards, Osier -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list