At 04/12/2011 01:51 PM, Hu Tao Write:
> Sorry, I unexpectedly deleted text body.
>
> I changed the code like this:
>
> diff --git a/src/qemu/qemu_domain.c b/src/qemu/qemu_domain.c
> index c2a1f9a..8aad0b3 100644
> --- a/src/qemu/qemu_domain.c
> +++ b/src/qemu/qemu_domain.c
> @@ -514,7 +514,10 @@ int qemuDomainObjBeginJobWithDriver(struct qemud_driver *driver,
> else
> virReportSystemError(errno,
> "%s", _("cannot acquire job mutex"));
> + virDomainObjUnlock(obj);
> qemuDriverLock(driver);
> + virDomainObjLock(obj);
We lock qemu_driver and vm as the folling steps:
1. lock qemu_driver
2. lock vm
We try to lock qemu_driver while holding the vm's lock.
OOps, it will cause the libvirtd deadlock.(I can reproduce this bug by your script)
> + virDomainObjUnref(obj);
We have unref it, so do not unref it again.
> return -1;
> }
> }
>
> but still have problem. (see log in previous mail.) The reference count
> of virDomainObj becomes 0 while there are still threads accessing it.
> This causes two results: one is segmentation fault as shown in the log;
> the other is the qemu monitor fd is closed two early, and threads are
> polling a closed fd.
>
> Steps of my test:
>
> 1. change the value of max_clients in /etc/libvirt/libvirtd.conf to
> big enough value:
>
> max_clients = 2000000
>
> 2. run libvirtd
>
> 3. run libvirt-test.sh hut-vm1 (hut-vm1 is my vm name) (warning: this
> script forks many processes you have to kill by hand)
>
> (again, the log and script libvirt-test.sh are in my previous mail)
>
> --
> libvir-list mailing list
> libvir-list@xxxxxxxxxx
> https://www.redhat.com/mailman/listinfo/libvir-list
>
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list