[Date Prev][Date Next] [Thread Prev][Thread Next]
[Thread Index]
[Date Index]
[Author Index]
Re: [Libvir] [PATCH] avoid virsh hang due to missing virDomainFree(dom) call
- From: Jim Meyering <jim meyering net>
- To: "Daniel P. Berrange" <berrange redhat com>
- Cc: Libvirt <libvir-list redhat com>
- Subject: Re: [Libvir] [PATCH] avoid virsh hang due to missing virDomainFree(dom) call
- Date: Wed, 30 Jan 2008 18:36:37 +0100
"Daniel P. Berrange" <berrange redhat com> 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.
[Date Prev][Date Next] [Thread Prev][Thread Next]
[Thread Index]
[Date Index]
[Author Index]