From mboxrd@z Thu Jan 1 00:00:00 1970 From: Gerd Knorr Subject: Re: "xm save" trouble -- deadlock? Date: Tue, 01 Nov 2005 18:15:27 +0100 Message-ID: <4367A2AF.2090707@suse.de> References: <43679B4C.3030804@suse.de> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <43679B4C.3030804@suse.de> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Gerd Knorr Cc: xen-devel List-Id: xen-devel@lists.xenproject.org > 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 > 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, 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