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

[BUG] Regression (SEGFAULT) in svn_wc_ensure_adm3 and 4 (introduced in r36758?)

From: Joe Swatosh <joe.swatosh_at_gmail.com>
Date: Fri, 11 Sep 2009 09:23:01 -0700

Hi Hyrum,

I spent last night trying to figure out why the Ruby bindings test of
Svn::Wc.ensure_adm is SEGFAULTing locally (I guess this is the same problem
in the buildbot for the bindings).

It turns out I can prevent the SEGFAULT by passing in a non-null repos
argument in the test. I wish I had remembered seeing this reported by kou as
a problem a long time ago:
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2126603

The bindings wrap svn_wc_ensure_adm3 which forwards to svn_wc_ensure_adm4. It
appears the the Ruby bindings tests are the only place where passing a null
repos value to svn_wc_ensure_adm4 is tested :-(.

Even after using a non-null repos, the test still errors (no SEGFAULT) unless
a non-null uuid is used. But, from svn_wc.h:
         * @a depth must be a definite depth, it cannot be @c svn_depth_unknown.
         * @a uuid and @a repos may be @c NULL. If non-_at_c NULL, @a repos must
         * be a prefix of @a url.
it seems that nulls should be allowed for both these arguments.

So the state of things is that I can make the test pass, but it seems wrong to
me to do so. What is your advice? I suppose if we decide it is best to
modify the test at the very least the doc string should be updated.

The repos *might* be fixed by changing SVN_PATH_IS_EMPTY in dirent_uri.c to
consider null empty, but this touches a lot of other places, so I don't know
all the consequences and I can't run the full test suite currently.

I have no idea about the uuid issue.

--
Joe
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2393654
Received on 2009-09-11 18:23:12 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.