On 11/23/2010 11:49 AM, Nikola Ciprich wrote:
> Hello,
> I noticed that libvirtd sometimes crashes immediately after start..
> here's the backtrace:
>
> Core was generated by `libvirtd --daemon --listen'.
> Program terminated with signal 11, Segmentation fault.
> #0 0x00007fee038c0ca0 in pthread_mutex_lock () from /lib64/libpthread.so.0
> (gdb) bt
> #0 0x00007fee038c0ca0 in pthread_mutex_lock () from /lib64/libpthread.so.0
> #1 0x000000000042eb21 in qemuDomainObjEnterMonitor (obj=0xe417d0) at qemu/qemu_driver.c:478
> #2 0x0000000000448e7e in qemudDomainGetInfo (dom=<value optimized out>, info=0x43392e10) at qemu/qemu_driver.c:5165
Unfortunately, I'm not seeing a local race:
} else if (!priv->jobActive) {
if (qemuDomainObjBeginJob(vm) < 0)
goto cleanup;
if (!virDomainObjIsActive(vm))
err = 0;
else {
qemuDomainObjEnterMonitor(vm);
err = qemuMonitorGetBalloonInfo(priv->mon, &balloon);
qemuDomainObjExitMonitor(vm);
}
That properly grabs the job lock, verifies that the vm is still active,
and then uses the monitor. The only other thing I can think of is a
non-local race that I'm not seeing in the immediate vicinity; perhaps
one thread is able to see the vm object prior to another thread
finishing the creation of the monitor lock, so that querying the domain
info ends up calling pthread_mutex_lock on an invalid mutex? But that
shouldn't be possible - object creation is also done under a lock, so
nothing should be able to see a partially initialized object.
Is this something you can easily repeat? Can you reproduce it while a
debugger is attached, or have you been limited to post-mortem debugging
so far? I'm a bit stumped on what to look for next.
--
Eric Blake eblake@xxxxxxxxxx +1-801-349-2682
Libvirt virtualization library http://libvirt.org
Attachment:
signature.asc
Description: OpenPGP digital signature
-- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list