On 2016-02-19 16:28, David Rothenberger wrote: > Greg Chicares wrote: [...] >> /lmi/mirror/lmi[1]$svn update >> Updating '.': >> zsh: segmentation fault (core dumped) svn update [...non-helpful stackdump...] >> I'll try running 'svn' under 'gdb'. Is there anything else I can do to help? > > That's the only other thing I can think of. If you can catch the > segfault and get a backtrace, I may be able to track it down.
Thanks. The problem is no longer occurring. Let me state what I know for the record in case it helps someone else someday. This seems to be a heisenbug. When I ran it under gdb, repeatedly, it refused to segfault. Outside gdb, with subversion-debuginfo installed, I was unable to get a useful stackdump. The problem has occurred only when gnu.org's svn server is slow: on one isolated occasion a week or two ago, and throughout today. And today there seems to have been a DDOS attack on gnu.org: https://savannah.gnu.org/support/?108973 While the problem lasted, sometimes I got one or both of these messages: svn: E170013: Unable to connect to a repository svn: E175012: Connection timed out and sometimes svn segfaulted with no message. I tried the same operations on my debian-7 ("wheezy") system with its older svn-1.6.17, where I got timeouts but no segfault. My real problem was the gnu.org server. I can only conjecture that attempting to work with a server under extreme load causes svn-1.9.3-1 to follow some exceptional code path that attempts to report a diagnostic and in doing so sometimes crashes. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
