[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: crash in latest release

From: Johan Corveleyn <jcorvel_at_gmail.com>
Date: Tue, 9 Oct 2012 22:35:57 +0200

On Tue, Oct 9, 2012 at 10:30 PM, Stefan Küng <tortoisesvn_at_gmail.com> wrote:
> On 09.10.2012 22:25, Johan Corveleyn wrote:
>>
>> On Tue, Oct 9, 2012 at 10:15 PM, Branko Čibej <brane_at_wandisco.com> wrote:
>>>
>>> On 09.10.2012 21:49, Stefan Küng wrote:
>>>>
>>>> Hi,
>>>>
>>>> Just got the first crash report for the TSVN 1.7.10 release (svn 1.7.7).
>>>> Considering that the release is only an hour old, that indicates that
>>>> I will get a lot more of those...
>>>>
>>>> Problem in libsvn_subr/win32_crypto.c, function
>>>> windows_password_decrypter(svn_boolean_t *done, ...):
>>>>
>>>> ...
>>>> if (!done)
>>>> return SVN_NO_ERROR;
>>>>
>>>>
>>>> now here the check is for the pointer, not the actual bool value.
>>>> And if it's set to false, the pointer check is still true and the code
>>>> goes on instead of returning here.
>>>>
>>>> trunk and 1.7.x have the same bug, even though on trunk the code
>>>> before the if() is slightly different.
>>>>
>>>> I think this needs to change to:
>>>>
>>>> if (!*done)
>>>> return SVN_NO_ERROR;
>>>
>>>
>>> You're right. Fixed in r1396285 but I don't have a way to test it.
>>>
>>> I don't know why our test suite didn't catch this; it should trigger
>>> every time an encrypted password is read from disk on Windows. But maybe
>>> the testsuite doesn't even test that.
>>
>>
>> I doubt that it can be triggered by simply reading an encrypted
>> password from %APPDATA%\Subversion\auth\svn.simple, if that's what you
>> mean. Otherwise I would have definitely run into the crash (if not
>> during the testsuite, I would have seen it during my manual testing of
>> serf checkouts/exports, on my work pc).
>
>
> Not necessarily: in my debug builds, it doesn't crash. Only the release
> builds crash because the strlen() there accesses an invalid pointer, while
> in the debug build the char* gets a 'initialized' to a valid string.
> depending on your build, the
>
> char *in;
>
> might point to some valid memory and therefore not crash (as it does in my
> debug builds).

I used a release build (I always test with a release build), built
with Visual C Express 2008 on Windows XP. But indeed, it might depend
on the build ... I was probably lucky, or unlucky, depending on how
you look at it :-/ ...

-- 
Johan
Received on 2012-10-09 22:36:50 CEST

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.