On 2008-10-14 18:12:07 +0200, Andreas Beckmann wrote: > if I press Ctrl-C during a svn operation, svn often does not terminate > properly.
This problem has just occurred on one of my machines, also with subversion/1.5.1dfsg1-1. Here's what a "strace -p" gives when I type Ctrl-C several times: read(6, 0x7fff74d7fcb0, 256) = ? ERESTARTSYS (To be restarted) --- SIGINT (Interrupt) @ 0 (0) --- read(6, 0x7fff74d7fcb0, 256) = ? ERESTARTSYS (To be restarted) --- SIGINT (Interrupt) @ 0 (0) --- read(6, 0x7fff74d7fcb0, 256) = ? ERESTARTSYS (To be restarted) --- SIGINT (Interrupt) @ 0 (0) --- read(6, 0x7fff74d7fcb0, 256) = ? ERESTARTSYS (To be restarted) --- SIGINT (Interrupt) @ 0 (0) --- read(6, 0x7fff74d7fcb0, 256) = ? ERESTARTSYS (To be restarted) --- SIGINT (Interrupt) @ 0 (0) --- read(6, 0x7fff74d7fcb0, 256) = ? ERESTARTSYS (To be restarted) --- SIGINT (Interrupt) @ 0 (0) --- Concerning the svn process and its children, I get: vlefevre 15754 31758 0 16:41 pts/5 00:00:00 svn ci vlefevre 15820 15754 0 16:41 pts/5 00:00:00 [zsh] <defunct> ($SVN_SSH is a ssh wrapper written in zsh, hence the zsh zombie process). And a backtrace: (gdb) bt #0 0x00007f796ba487a0 in __read_nocancel () from /lib64/libpthread.so.0 #1 0x00007f796bc6c635 in apr_file_read () from /usr/lib/libapr-1.so.0 #2 0x00007f796ac89f81 in ?? () from /usr/lib/libsvn_ra_svn-1.so.1 #3 0x00007f796ac87ebf in ?? () from /usr/lib/libsvn_ra_svn-1.so.1 #4 0x00007f796ac87fc5 in ?? () from /usr/lib/libsvn_ra_svn-1.so.1 #5 0x00007f796ac824aa in ?? () from /usr/lib/libsvn_ra_svn-1.so.1 #6 0x00007f796ac82b78 in ?? () from /usr/lib/libsvn_ra_svn-1.so.1 #7 0x00007f796c4e4824 in svn_ra_open3 () from /usr/lib/libsvn_ra-1.so.1 #8 0x00007f796c958c57 in svn_client__open_ra_session_internal () from /usr/lib/libsvn_client-1.so.1 #9 0x00007f796c9352ae in ?? () from /usr/lib/libsvn_client-1.so.1 #10 0x00007f796c936463 in svn_client_commit4 () from /usr/lib/libsvn_client-1.so.1 #11 0x0000000000406c9a in ?? () #12 0x000000000040d6bb in ?? () #13 0x00007f796b7061a6 in __libc_start_main () from /lib64/libc.so.6 #14 0x0000000000405649 in ?? () #15 0x00007fff74d80898 in ?? () #16 0x000000000000001c in ?? () #17 0x0000000000000002 in ?? () #18 0x00007fff74d81fd5 in ?? () #19 0x00007fff74d81fd9 in ?? () #20 0x0000000000000000 in ?? () Not really useful, unfortunately, but doesn't it say that the problem comes from libapr? FYI, I have libapr1 1.2.12-5. Note: it is probably bug 461873, which I reported a few months ago. But then I could no longer reproduce it (until now) and this bug is archived. > For instance, I may want to abort a 'svn update' that retrieves a lot of > updates over a slow connection. Svn does somehow stop processing the > update command, but it still receives data (all the remaining data?) > from the network which may actually continue blocking the slow line that > I wanted to free by aborting the update. > Also the svn command still running is not interruptable by any other > means (more ^C or signals) except for SIGKILL (which sometimes results > in a repository that can't even be fixed by 'svn cleanup' any more). > The same seems to be valid for the checkout command. And commit (my case here). The connection is not slow here and it was a very small commit, but there are sometimes problems with the server. I think that if svn receives the SIGINT signal while the connection has not terminated, it can sometimes get stuck somewhere, with no possibility of recovery. -- Vincent Lefèvre <[EMAIL PROTECTED]> - Web: <http://www.vinc17.org/> 100% accessible validated (X)HTML - Blog: <http://www.vinc17.org/blog/> Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
