>
> 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.
>
Hello Eric,
crashes always occur when libvirt is starting, no machines are running at that time..
Dunno if this information can help...?
Maybe it might be possible to edit initscript to start libvirt in gdb?
n.
--
-------------------------------------
Ing. Nikola CIPRICH
LinuxBox.cz, s.r.o.
28. rijna 168, 709 01 Ostrava
tel.: +420 596 603 142
fax: +420 596 621 273
mobil: +420 777 093 799
www.linuxbox.cz
mobil servis: +420 737 238 656
email servis: servis@xxxxxxxxxxx
-------------------------------------
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list