You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by "Yuval E." <gy...@gmail.com> on 2013/10/13 10:37:58 UTC
Re: SilkSVN client crashing
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 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