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.
[1] http://mail-archives.apache.org/mod_mbox/apr-dev/201309.mbox/%3CCABw-3YfNKWfHrjPKxPF_BoUKOyG05KTxP-rEh0oW2fVa4NGShA%40mail.gmail.com%3E
--
Ivan Zhakov
Received on 2013-09-12 16:48:50 CEST