You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Ivan Zhakov <iv...@visualsvn.com> on 2013/09/12 16:47:56 UTC
Re: SilkSVN client crashing
On Thu, Sep 5, 2013 at 11:37 AM, Bjarne Grönnevik
<Bj...@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.
[1] http://mail-archives.apache.org/mod_mbox/apr-dev/201309.mbox/%3CCABw-3YfNKWfHrjPKxPF_BoUKOyG05KTxP-rEh0oW2fVa4NGShA%40mail.gmail.com%3E
--
Ivan Zhakov
Re: SilkSVN client crashing
Posted by Ivan Zhakov <iv...@visualsvn.com>.
On 13 October 2013 12:37, Yuval E. <gy...@gmail.com> wrote:
> 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?
>
It looks like the same issue.
--
Ivan Zhakov
CTO | VisualSVN | http://www.visualsvn.com
Re: SilkSVN client crashing
Posted by "Yuval E." <gy...@gmail.com>.
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.
Re: SilkSVN client crashing
Posted by Ivan Zhakov <iv...@visualsvn.com>.
On Thu, Sep 12, 2013 at 6:47 PM, Ivan Zhakov <iv...@visualsvn.com> wrote:
> On Thu, Sep 5, 2013 at 11:37 AM, Bjarne Grönnevik
> <Bj...@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