On Thu, Sep 12, 2013 at 6:47 PM, Ivan Zhakov <ivan_at_visualsvn.com> wrote:
> On Thu, Sep 5, 2013 at 11:37 AM, Bjarne Grönnevik
> <Bjarne.Gronnevik_at_netent.com> wrote:
> [moving to dev_at_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_at_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
Received on 2013-09-13 18:06:24 CEST