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

Re: Release build serf test failures

From: Paul Burba <ptburba_at_gmail.com>
Date: Tue, 3 Nov 2009 12:19:05 -0500

On Mon, Nov 2, 2009 at 8:51 PM, Paul Burba <ptburba_at_gmail.com> wrote:
> On Mon, Nov 2, 2009 at 6:52 PM, Paul Burba <ptburba_at_gmail.com> wrote:
>> On Thu, Oct 29, 2009 at 12:24 PM, Lieven Govaerts <svnlgo_at_mobsol.be> wrote:
>>> On Thu, Oct 29, 2009 at 5:08 PM, Paul Burba <ptburba_at_gmail.com> wrote:
>>>> Could someone confirm if merge_tests.py 76 fails on trunk_at_40272 when
>>>> running a *release* build over ra_serf?  This test, and those listed
>>>> below, all pass for me over neon or when using a serf and a debug
>>>> build, but when using a release build I consistently get a 'svn:
>>>> Premature EOF seen from server' error.
>>>> merge_tests.py 76: subtrees added after start of merge range are ok
>>>> merge_tests.py 93: dont merge revs into a subtree that predate it
>>>> merge_tests.py 98: subtree merge source might not exist
>>>> merge_tests.py 122: subtree gets changes even if ultimately deleted
>>>> merge_authz_tests.py 2: merge fails if subtree is deleted on src
>>> No such problems on Ubuntu with a release build. Do you have something
>>> like valgrind to check memory initialization?
>> I tried Object Media's Memory Validator, but it didn't find any
>> initialization problems.  I'm beating my head against the $#@! wall
>> with this one.
>> I didn't mention this before, but as Mark noted, merge_tests.py 78
>> fails too, but unlike the other failures this is a segfault.
>> Paul
> Bert,
> If you (or anybody else on Windows) has any suggestions as to what
> might be causing these release only failures, or ideas on how to track
> them down, I'd be in your debt to hear them.  I'm at a dead-end on
> these.  Even if you could only confirm the failures that would be
> helpful (well it would be helpful if you don't see them).
> Paul

Potentially some light at the end of the tunnel (likely an oncoming
train). On a hunch (or was it out of desperation?) I looked back for
changes in libsvn_ra_serf back that could have caused these failures.
Updating only libsvn_ra_serf I found that the error in merge_tests.py
76 and the segfault in merge_tests.py 78 both started with r38105:

Make all response handlers in svn_ra_serf return svn_error_t* for
a much cleaner error handling. This fixes issue #3375, but some further
refactoring would be welcome.

Still can't see how this is causing the premature EOF and segfault,
but it's something.


Received on 2009-11-03 18:19:22 CET

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