"Daniel P. Berrange" <berrange@xxxxxxxxxx> wrote: > On Wed, Jan 30, 2008 at 06:25:19PM +0100, Jim Meyering wrote: >> Without the following patch, this command would hang >> >> printf 'domuuid fc4\ndomstate fc4\n' \ >> | ./virsh --connect test://$PWD/../docs/testnode.xml >> >> with this stack trace: >> >> __lll_lock_wait ... >> _L_lock_105 ... >> __pthread_mutex_lock ... >> virUnrefDomain (domain=0x6a8b30) at hash.c:884 >> virDomainFree (domain=0x6a8b30) at libvirt.c:1211 >> cmdDomstate (ctl=0x7fffea723390, cmd=0x6a8b10) at virsh.c:677 >> vshCommandRun (ctl=0x7fffea723390, cmd=0x6a8b10) at virsh.c:4033 >> main (argc=3, argv=0x7fffea7234e8) at virsh.c:501 >> >> The problem is that cmdDomuuid didn't call virDomainFree(dom), so >> cmdDomstate hangs trying to do the Unref. > > I don't understand why it would hang simply because it forgot to free > an object. Surely it ought to just be a memory leak not hang ? Each > individual libvirt API must always have a matched lock & unlock pair > in all codepaths, so a hang should only occur if an unlock is missing > in some codepath. Well maybe virDomainFree is misnamed then. It does more: The missing virDomainFree calls cause that because they are what is supposed to do the unlock. virDomainFree calls virUnrefDomain, which calls virReleaseDomain (when refs hits 0), which calls pthread_mutex_unlock. -- Libvir-list mailing list Libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list