On Thu, Sep 12, 2013 at 6:47 PM, Ivan Zhakov <i...@visualsvn.com> wrote: > On Thu, Sep 5, 2013 at 11:37 AM, Bjarne Grönnevik > <bjarne.gronne...@netent.com> wrote: > [moving to dev@s.a.o] >> 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
