Blocking calls are generally not interuptable on windows. Select, recv, etc. If paramiko is in the mix, I wonder if it is a small ssh incompatibility. Like not supporting re-keying that we saw in the past. That particular one doesn't fit here, though. John =:-> <div class="gmail_quote">On Oct 5, 2011 12:13 AM, "Martin Pool" <<a href="mailto:mbp@canonical.com">mbp@canonical.com</a>> wrote: > On 5 October 2011 04:52, Eli Zaretskii <<a href="mailto:eliz@gnu.org">eliz@gnu.org</a>> wrote: >>> From: Martin Pool <<a href="mailto:mbp@canonical.com">mbp@canonical.com</a>> >>> Date: Tue, 4 Oct 2011 12:16:18 +1100 >>> Cc: <a href="mailto:bazaar@lists.canonical.com">bazaar@lists.canonical.com</a> >>> >>> I don't know, based on that, what it would be, but the general kind of >>> thing I would try to find out next in this type of situation is just >>> what is going on when it is hanging: what is bzr doing, what is the >>> external ssh transport (if any) doing, and what is the OS tcp socket >>> doing? >> >> It looks like bzr is waiting forever in `select'. Here's the stack of >> one of the two threads shown by Process Explorer: >> >> ntoskrnl.exe!ExReleaseResourceLite+0x2be >> ntoskrnl.exe!IoPageRead+0xc50 >> ntoskrnl.exe!IoGetBaseFileSystemDeviceObject+0x730 >> ntoskrnl.exe!NtWaitForSingleObject+0x94 >> ntoskrnl.exe!KiDeliverApc+0xbbb >> ntdll.dll!KiFastSystemCallRet >> MSWSOCK.dll+0x5fa7 >> WS2_32.dll!select+0xa7 >> _socket.pyd!init_socket+0x1c6e >> >> I have no idea what that means. Why would it wait forever? aren't >> there timeouts? am I looking at some deadlock in the kernel? > > select is used to wait for network io. When a connection is active we > typically wait forever to be able to read or write. (Perhaps there > should be a very long timeout where bzr decides for itself the network > has jammed, but for the moment we rely on the user.) > > So the question then is: which fds is it waiting on (what are the > arguments to select?) and which sockets do they correspond to, and > what does the OS think the state of those sockets is (which is the > netstat output.) > >>> * pop into the bzr debugger with ctrl-break and then get a backtrace >>> (type 'bt') >> >> Ctrl-Break doesn't seem to be able to interrupt bzr in this state, >> probably because it is stuck inside a system call. > > That's a little strange, because select is interruptible on unix, but > perhaps not on Windows. > >>> * is there a windows equivalent to 'netstat -ponet' that shows the >>> socket state? >> >> The socket state is ESTABLISHED, if this is what you wanted to know. > > OK, but I'd also like to know the length of the rx and tx queues, and > which timer is active if any, and if so what its value and counter is. > > Thanks. > > m > </div>