Hi,
[[[
More test coverage for the svn.wc Python bindings.
*
(setUp): Acquire write lock on wc
(tearDown): Explicitly close wc
(test_lock): Add tests for add_lock and remove_lock
(test_version): Add test for version()
(test_is_adm_dir): Add test for is_adm_dir()
(test_get_adm_dir): Add test for get_adm_dir()
(test_set_adm_dir): Add test for set_adm_dir()
(test_init_traversal_info): Add test for init_traversal_info()
(test_create_notify): Add test for create_notify()
(test_check_wc): Add test for test_wc()
]]]
Cheers,
Jelmer

Wed, 2006-06-14 at 15:14 -0400, Garrett Rooney wrote:
6/14/06, Jelmer Vernooij <jelmer (AT) samba (DOT) orgwrote:
(test_check_wc): Add test for test_wc()

It looks like this will break on builds from a tarball, as opposed to
checked out from svn. does the test framework chdir into a working
copy it checks out or something like that?
Yes, self.path gets set to a temporary directory that contains a working
copy made from an example repository (see setUp(), which does a checkout
and sets self.path).

Cheers,

Jelmer

Fri, 2006-06-16 at 11:35 +0530, Madan U Sreenivasan wrote:
Fri, 16 Jun 2006 05:27:34 +0530, Jelmer Vernooij <jelmer (AT) samba (DOT) org
wrote:
<<
madan@madan ~/wc/trunk $ gdb python2.4

GNU gdb 6.4
Copyright 2005 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you
are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i386-pc-linux-gnu"(no debugging symbols
found)
Using host libthread_db library "/lib/libthread_db.so.1".

(gdb) r
Starting program: /usr/bin/python2.4

(no debugging symbols found)
(no debugging symbols found)
[Thread debugging using libthread_db enabled]
[New Thread 16384 (LWP 7355)]
start of SubversionRepositoryTestSetup
after dumpfile open
After tearDown
Before creating repos at :/tmp/trac-svnrepos:

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 16384 (LWP 7355)]
0x4048180e in apr_palloc () from /usr/lib/libapr-0.so.0
(gdb) bt
#0 0x4048180e in apr_palloc () from /usr/lib/libapr-0.so.0
#1 0x4066f8dc in create_svn_repos_t (path=0x403ef3c4
"/tmp/trac-svnrepos", pool=0x0) at repos.c:1540
#2 0x4066fc00 in svn_repos_create (repos_p=0x0, path=0x403ef3c4
"/tmp/trac-svnrepos", unused_1=0x402b90ac "",
unused_2=0x402b90ac "", config=0x0, fs_config=0x0, pool=0x0) at
repos.c:1664
#3 0x408f368a in ? () from
/
#4 0xbffaf8dc in ? ()
#5 0x403ef3c4 in ? ()
#6 0x402b90ac in ? ()
#7 0x402b90ac in ? ()
#8 0x00000000 in ? ()
(gdb) c
Continuing.

Program terminated with signal SIGSEGV, Segmentation fault.
The program no longer exists.
(gdb)
<<

PS : I have put some simple print statements, whose output you will see
just before the SIGSEGV

I will try with my laptop at office today looking at the bt, I
suspect linkages with older versions of libapr what do you think?
I'm not sure - if pool=NULL is a valid argument to create_svn_repos_t(),
then at least the Python bindings are not to blame. This must've been
broken longer though - this is code that's being called from the trac
test cases.

I'm using libapr-1 (you appear to be using libapr-0), so you might want
to try that version. Is subversion supposed to work with any particular
version of libapr or should any do?

Cheers,

Jelmer

Madan U Sreenivasan wrote:
Why is the class called SubversionRepositoryTestCase? Shouldn't it be
SubversionWorkingCopyTestCase?

Good point. Yeah, that'd be better.

Also, am not sure about this, but wont it be much clearer, if the log file
referred to the functions with the class.function() convention?

If the file in question contains only one class, you can just use the
function name.

<<
madan@madan ~/wc/trunk $ gdb python2.4

#0 0x4048180e in apr_palloc () from /usr/lib/libapr-0.so.0
#1 0x4066f8dc in create_svn_repos_t (path=0x403ef3c4
"/tmp/trac-svnrepos", pool=0x0) at repos.c:1540
#2 0x4066fc00 in svn_repos_create (repos_p=0x0, path=0x403ef3c4
"/tmp/trac-svnrepos", unused_1=0x402b90ac "",
unused_2=0x402b90ac "", config=0x0, fs_config=0x0, pool=0x0) at
repos.c:1664
#3 0x408f368a in ? () from
/

You're using an old version of the Python bindings with a new
version of Subversion. I can tell this from the stack trace because
your Subversion build has debug symbols but your Python bindings build
does not. Also, I can see that you're running Python bindings from
'/usr/lib', and it is unusual to keep your trunk bindings in
'/usr/lib'.

Madan, have you tried running the regular 'make check-swig-py' target?
This target automatically sets up your Python path so that the tests
will run with the version of the Python bindings in your build tree.
You may also need to run 'make clean-swig && ./configure' if you want
to get a completely clean build.

I will try with my laptop at office today looking at the bt, I
suspect linkages with older versions of libapr what do you think?
I'm not sure - if pool=NULL is a valid argument to create_svn_repos_t(),
then at least the Python bindings are not to blame. This must've been
broken longer though - this is code that's being called from the trac
test cases.

pool=NULL is not a valid argument to create_svn_repos_t or svn_repos_create.

I'm using libapr-1 (you appear to be using libapr-0), so you might want
to try that version. Is subversion supposed to work with any particular
version of libapr or should any do?

Subversion should work with either libapr-1 or libapr-0.

Cheers,

David

6/15/06, Madan U Sreenivasan <madan (AT) collab (DOT) netwrote:
pool=NULL is not a valid argument to create_svn_repos_t or
svn_repos_create.

Is it? svn.repos.create() complains that it needs 5 parameters as input,
when I give less than that. I cant figure out which five Also, there is
no apr_pool_create() function in svn.core (pool related functions are
documented as deprecated) so how do we create a pool to be passed to
svn.repos.create()?

The signature for svn.repos.create in the Python bindings is:
new_repos = svn.repos.create(path, unused_1, unused_2, config, fs_config, pool)

In the Python bindings, the pool argument is optional. If you do not
specify it, a temporary pool will be generated for you automatically.

To generate a new pool, use the svn.core.Pool() function. Pools are
only needed in the Python bindings if you want to have fine-grained
control over how Python manages memory, which you usually do not need.

the other hand, in C, the 'Pool' argument is not optional, and must
be specified. If you supply 'NULL' as the pool value, you will likely
provoke a segfault.

In general, the differences between the regular Subversion library and
the Python bindings are not very well documented, so you will often be
left guessing while you are using the bindings. Still, guessing isn't
that bad -- you can often guess how a function works by looking at its
header and figuring out what its 'input' and 'output' parameters are.

Here's a conversion rule. In C, you might see:
svn_error_t * svn_lib_function(svn_foo_t **output1, svn_foo_t
*input1, svn_foo_t *input2, svn_foo_t **output2, apr_pool_t *pool)

In Python, this converts to:
output1, output2 = svn.lib.function(input1, input2, pool)

where the "pool" argument is optional, and should probably be left
out in typical usage.

Note that output arguments in C tend to be doubly indirect pointers
(i.e. two asteriks).

For examples of scripts which use the Python bindings, see the tools
and contrib directories. If you're looking to write new test scripts,
I'd recommend looking at those scripts first, and checking what
functionality is exercised by those scripts (in tools and contrib)
that is not yet exercised by our test suite.

Cheers,

David