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

Re: svn commit: r33528 - in trunk/subversion: include libsvn_delta libsvn_wc

From: Joe Swatosh <joe.swatosh_at_gmail.com>
Date: Mon, 13 Oct 2008 22:36:41 -0700

On Mon, Oct 13, 2008 at 5:02 AM, Greg Stein <gstein_at_gmail.com> wrote:
> On Sun, Oct 12, 2008 at 4:10 PM, Joe Swatosh <joe.swatosh_at_gmail.com> wrote:
>>...
>> line 47 is the marked assertion. So it appears that
>> svn_txdelta_md5_digest is returning a different value than it used to.
>>
>> Not sure if its significant, but I was interested in your opinion
>> about if there is a better way to test this or if the problem is the
>> changed return value.
>
> I just added a new test: subversion/tests/libsvn_delta/window-test.c.
> That appears to show the digest is being returned properly.
>
> Without further pointers, I'm going to assume that there is some
> memory corruption in how Ruby transfers that digest into a Ruby value.
> Note that the first half of the digest is the same as the expected
> value, but the last half has 0x44 ('D'), then a combo of 0x33 ('3')
> and 0x34 ('4') values. Given the way that MD5 works, I am *extremely*
> suspicious that a hash was able to match the first eight bytes.
>
> Oh. And I think that I see the problem. I added a "result_pool" into
> the txstream baton for allocation of the checksum, but didn't actually
> use it! I've just fixed that and committed (r33613). Please try your
> test again.
>

Ta, Greg. Ruby bindings tests are green again at r33613 (with a few
patches for other issues that I hope to be committing soon).

Thanks again,

--
Joe Swatosh
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-10-14 07:36:56 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.