Ivan Zhakov-2 wrote > On Thu, Sep 12, 2013 at 6:47 PM, Ivan Zhakov <
> ivan@ > > wrote: >> On Thu, Sep 5, 2013 at 11:37 AM, Bjarne Grönnevik >> < > Bjarne.Gronnevik@ > > wrote: >> [moving to > dev@.a > ] >>> Hi >>> >>> I’m scripting svn via a Python Script and as you can see in the >>> run-log.txt, >>> svn seems to fail at random occasions(see crash logs). Or at least for >>> reasons unknown to me. >>> >>> And as the error message suggest helping out by mailing here, I did. >>> >>> Svn version is: svn, version 1.8.1-SlikSvn-1.8.1-X64 (SlikSvn/1.8.1) >>> X64, >>> compiled Aug 26 2013, 16:52:34 on x86_64/x86-microsoft-windows6.1.7601 >>> >>> Os is: Windows 7 Enterprice, 64-bit, Service Pack 1 >>> >> Bert Huijben found very easy way to reproduce this problem: >> [On Windows] >> >> 1. svn log http://svn.apache.org/repos/asf --limit 100 | more >> 2. Then press 'q' >> >> Client crashes. >> >> I can reproduce it with trunk and 1.8.x (debug build). >> >> The problem that we get ERROR_NO_DATA from fflush() call in >> svn_cmdline_fflush() when 'more' quits due 'q' key. Then svn_error_t >> with apr_err = ERROR_NO_DATA passed through layers to serf. For some >> reason APR_STATUS_IS_EAGAIN(ERROR_NO_DATA) is true, so serf just >> ignores this error and wait for more data from network. Next chunk >> received and ra_serf parser called again despite that parser returned >> error and doesn't expect to be called again. Crash itself happens >> because it accesses already cleared error, but the real problem that >> xml parser should not be invoked. >> >> There are several problems here: >> 1. Why APR considers ERROR_NO_DATA as EAGAIN. I've posted question to >> dev@apr mailing list [1] >> >> 2. ra_serf passes arbitrary errors to serf, while serf threats APR_EOF >> and APR_EAGAIN as special value. We should not doing this. >> >> > Filed as issue #4425. Fixed this specific case in r1522892, but > problem that arbitrary errors are passed to serf from xml parser is > not fixed yet. > > -- > Ivan Zhakov > CTO | VisualSVN | http://www.visualsvn.com I'm experiencing a similar problem with SlikSVN 1.8.3: svn, version 1.8.3-SlikSvn-1.8.3-WIN32 (SlikSvn/1.8.3) WIN32 compiled Sep 16 2013, 13:42:00 on x86-microsoft-windows6.1.7601 However, in my case pressing 'q' doesn't crash the client immediately - instead it just freezes. When I eventually hit Ctrl-C, it crashes. I get the same results if I pipe into 'head -n 1' instead of 'more'. Is this likely due to the same root cause as #4425, or should I report it as a new issue? Thanks, Yuval -- View this message in context: http://subversion.1072662.n5.nabble.com/Re-SilkSVN-client-crashing-tp184844p185210.html Sent from the Subversion Dev mailing list archive at Nabble.com.
