On 03/07/2011 03:03 AM, Daniel P. Berrange wrote:
>> I think the real reason for the deadlock is that:
>>
>> qemudDomainSaveFlag holds the domain lock while it calls
>> qemuDomainEventQueue, which requests the event loop lock
>>
>> the event loop thread holds the event loop lock, and can make sever
On Fri, Mar 04, 2011 at 06:03:36PM -0700, Eric Blake wrote:
> On 03/04/2011 02:46 PM, Eric Blake wrote:
> >> +++ b/src/qemu/qemu_process.c
> >> @@ -596,7 +596,9 @@ static void
> >> qemuProcessHandleMonitorDestroy(qemuMonitorPtr mon,
> >> qemuDomainObjPrivatePtr priv = vm->privateData;
> >>
On 03/04/2011 06:03 PM, Eric Blake wrote:
> I think the real reason for the deadlock is that:
>
> qemudDomainSaveFlag holds the domain lock while it calls
> qemuDomainEventQueue, which requests the event loop lock
>
> the event loop thread holds the event loop lock, and can make several
> differe
On 03/04/2011 02:46 PM, Eric Blake wrote:
>> +++ b/src/qemu/qemu_process.c
>> @@ -596,7 +596,9 @@ static void
>> qemuProcessHandleMonitorDestroy(qemuMonitorPtr mon,
>> qemuDomainObjPrivatePtr priv = vm->privateData;
>> if (priv->mon == mon)
>> priv->mon = NULL;
>> -virDomain
On 03/03/2011 12:47 PM, Laine Stump wrote:
> This was found while researching the root cause of:
>
> https://bugzilla.redhat.com/show_bug.cgi?id=670848
>
> virDomainUnref should only be called with the lock held for the
> virDomainObj in question. However, when a transient qemu domain gets
>
On 03/03/2011 12:47 PM, Laine Stump wrote:
> This was found while researching the root cause of:
>
> https://bugzilla.redhat.com/show_bug.cgi?id=670848
>
> virDomainUnref should only be called with the lock held for the
> virDomainObj in question. However, when a transient qemu domain gets
>
This was found while researching the root cause of:
https://bugzilla.redhat.com/show_bug.cgi?id=670848
virDomainUnref should only be called with the lock held for the
virDomainObj in question. However, when a transient qemu domain gets
EOF on its monitor socket, it queues an event which frees
