Re: "xm save" trouble -- deadlock?

[Gerd Knorr <kraxel@suse.de>]

> xend in turn doesn't read from the pipe but is waiting for some lock:
> 
>   master-xen root /vm/ttylinux# strace -p6567
>   Process 6567 attached - interrupt to quit
>   futex(0x8087370, FUTEX_WAIT, 0, NULL <unfinished ...>
>   Process 6567 detached

Oh, xend is multithreaded:

   master-xen root /vm/ttylinux# ls /proc/6567/task
   .  ..  6567  6568  6569  6570  6571  6581  7977

7977 seems to be responsible for the xc_save and does this:

   master-xen root /vm/ttylinux# strace -p7977
   Process 7977 attached - interrupt to quit
   read(20,  <unfinished ...>
   Process 7977 detached

fd 20 is the other end of the *stdout* pipe, whereas xc_save writes 
stuff to *stderr*.  Hmm.  Maybe xend causes the deadlock by simply 
reading from the wrong file handle?

Some of the other threads behave in a strange way as well:

   master-xen root /vm/ttylinux# strace -p6568
   Process 6568 attached - interrupt to quit
   select(4, [3], [], [], {0, 960000})     = 0 (Timeout)
   futex(0x80e53b8, FUTEX_WAKE, 1)         = 0
   accept(3, 0x408193f8, [110])            = -1 EAGAIN (Resource 
temporarily unavailable)

There is no point in calling accept(3) unless select() flags file handle 
#3 as readable.

Looks like I'll go browse some python code tomorrow ...

   Gerd