I'm using the svn ruby binding in a client-application to access several
repositories. Some of them are located in a local subnet, some are
reacheable through a firewall.
For this reason I need some entries in the '.subversion/servers' config
file
to declare the proxy's address.
[groups]
collabnet = svn.collab.net
[collabnet]
http-proxy-host = proxy
http-proxy-port = 8080
In the ruby script in the Svn::Client::Context object I read the config
files
and assign the result to the local variable 'config':
self.config=Svn::Core::Config.config( @cfgPath )
This works in principle, I can access any kind of server urls. But after
a
short time I get a sporadical segfault wich looks such as this:
(gdb) bt
#0 0x004a47a2 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2
#1 0x004e8955 in raise () from /lib/tls/libc.so.6
#2 0x004ea319 in abort () from /lib/tls/libc.so.6
#3 0x080c24a7 in rb_bug (fmt=0x80db89d "Segmentation fault") at
error.c:214
#4 0x080a6b44 in sigsegv (sig=11) at signal.c:447
#5 <signal handler called>
#6 svn_stringbuf_ensure (str=0x0, minimum_size=7)
at subversion/libsvn_subr/svn_string.c:342
#7 0xf6590e1b in svn_stringbuf_set (str=0x0, value=0xf65b495f "groups")
at subversion/libsvn_subr/svn_string.c:304
#8 0xf6584a5f in find_option (cfg=0x9325d90, section=0xf65b495f
"groups",
option=0x0, sectionp=0xfeee0f78) at
subversion/libsvn_subr/config.c:368
#9 0xf6585385 in svn_config_enumerate2 (cfg=0x9325d90,
section=0xf65b495f "groups", callback=0xf658542c <search_groups>,
baton=0xfeee0fb0, pool=0x93bc6c0) at
subversion/libsvn_subr/config.c:766
#10 0xf65854ae in svn_config_find_group (cfg=0x9325d90, key=0x0,
master_section=0xf65b495f "groups", pool=0xf65b495f)
at subversion/libsvn_subr/config.c:837
#11 0xf6575e77 in svn_ra_dav__open (session=0x0,
repos_URL=0x945f7f8
"http://heiapp00212/svn/SYS/Sfos/trunk/Src/Sfos/AnsiFileSystem.cpp",
callbacks=0x93bc6f8, callback_baton=0x0, config=0x932dd00,
pool=0x93bc6c0) at subversion/libsvn_ra_dav/session.c:665
#12 0xf653fca1 in svn_ra_open2 (session_p=0x0,
repos_URL=0x945f7f8
"http://heiapp00212/svn/SYS/Sfos/trunk/Src/Sfos/AnsiFileSystem.cpp",
callbacks=0x93bc6f8, callback_baton=0x93bc718,
config=0x932dd00, pool=0x93bc6c0) at
subversion/libsvn_ra/ra_loader.c:293
#13 0xf652395c in svn_client__open_ra_session_internal (
ra_session=0xfeee1174,
base_url=0x945f7f8
"http://heiapp00212/svn/SYS/Sfos/trunk/Src/Sfos/AnsiFileSystem.cpp",
base_dir=0x0, base_access=0x0, commit_items=0x0, use_admin=0,
read_only_wc=1, ctx=0x930ebe8, pool=0x93bc6c0)
at subversion/libsvn_client/ra.c:291
#14 0xf6523f55 in svn_client__repos_locations (start_url=0xfeee120c,
start_revision=0x0, end_url=0xfeee1214, end_revision=0x0,
path=0x98ac4a8
"/home/husteret/work/cpt.sys.local/HEAD/Sfos/Src/Sfos/AnsiFileSystem.cpp
", revision=0xfeee1240, start=0xfeee1230, end=0xfeee1220,
---Type <return> to continue, or q <return> to quit---
ctx=0x930ebe8, pool=0x90900a8) at subversion/libsvn_client/ra.c:747
#15 0xf652463e in svn_client__ra_session_from_path (ra_session_p=0x0,
rev_p=0x0, url_p=0x0,
path_or_url=0x98ac4a8
"/home/husteret/work/cpt.sys.local/HEAD/Sfos/Src/Sfos/AnsiFileSystem.cpp
", peg_revision_p=0xfeee13a0, revision=0xfeee1390,
ctx=0x930ebe8, pool=0x90900a8) at subversion/libsvn_client/ra.c:911
#16 0xf65209f8 in svn_client_info (
path_or_url=0x98ac4a8
"/home/husteret/work/cpt.sys.local/HEAD/Sfos/Src/Sfos/AnsiFileSystem.cpp
", peg_revision=0xfeee13a0, revision=0x0,
receiver=0xf650e9f0 <svn_swig_rb_info_receiver>,
receiver_baton=0xf613f200, recurse=0, ctx=0x930ebe8, pool=0x90900a8)
at subversion/libsvn_client/info.c:344
#17 0xf64f9e3b in _wrap_svn_client_info (argc=6, argv=0xfeee18c0,
self=4134158372) at subversion/bindings/swig/ruby/svn_client.c:8191
#18 0x0805bc3e in rb_call0 (klass=4134155392, recv=4134158372, id=81345,
oid=0, argc=6, argv=0xfeee18c0, body=0xf669de68, flags=-162554536)
at eval.c:5564
#19 0x080616b7 in method_call (argc=6, argv=0xfeee18c0, method=0)
at eval.c:9001
#20 0x0805bc3e in rb_call0 (klass=4143796864, recv=4129584232, id=5225,
oid=0, argc=6, argv=0xfeee18c0, body=0xf6fd51e0, flags=134616640)
at eval.c:5564
#21 0x0805c19f in rb_call (klass=4143796864, recv=4129584232, mid=5225,
argc=6, argv=0xfeee18c0, scope=0) at eval.c:5920
when I comment out the 'self.config= ..' line then I cant access servers
behind
the proxy but local servers are available. This works without any
faults.
On my way for searching this bug I suspected the pool-handling in
combination with
the ruby garbage collector, because the fault is sporadic and because
the
wrapper function for 'Svn::Core::Config.config' does many pool actions
which I can't
understand in a last consequence.
To verify this suspicion I wrote a small c-binding function which
directly
does the config read and the assignment to the 'config' variable in one
c-function. This avoids many buffer conversions and pool usage
and indeed the bug disappeared.
--- ./subversion-1.3.2-orig/subversion/bindings/swig/ruby/svn_client.c
2006-05-23 03:41:20.000000000 +0200
+++ ./subversion-1.3.2/subversion/bindings/swig/ruby/svn_client.c
2006-07-25 10:50:52.000000000 +0200
@@ -2726,6 +2726,25 @@
}
return vresult;
}
+static VALUE
+_wrap_svn_client_ctx_t_config_setFromFile(int argc, VALUE *argv, VALUE
self) {
+ svn_client_ctx_t *arg1 = (svn_client_ctx_t *) 0 ;
+ svn_error_t *result;
+
+ if ((argc < 1) || (argc > 1))
+ rb_raise(rb_eArgError, "wrong # of arguments(%d for 1)",argc);
+
+
+ SWIG_ConvertPtr(self, (void **) &arg1, SWIGTYPE_p_svn_client_ctx_t,
1);
+
+
+ result = (svn_error_t *)svn_config_get_config(&(arg1)->config,
+
StringValuePtr(argv[0]),
+
_svn_client_config_pool());
+
+
+ return Qnil;
+}
static VALUE
@@ -9230,6 +9249,7
rb_define_method(cSvn_client_ctx_t.klass, "config=",
_wrap_svn_client_ctx_t_config_set, -1);
+ rb_define_method(cSvn_client_ctx_t.klass, "configFromFile",
_wrap_svn_client_ctx_t_config_setFromFile, -1);
.
In my Svn::Client::Context-object I call this new method
'configFromFile' instead of the
variant before.
#self.config=Svn::Core::Config.config(@cfgPath)
configFromFile(@cfgPath)
I dont know if the pool handling in my method-wrapper is correct, but it
works much more
stable than the former one.
What is the problem here?
Do I use the wrong method? (i did not find another one)
Is there really a bug in the pool handling? (I cant comprehend)
thomas
PS.
By the way, I fear that in client.rb the most methods which use
a 'rev' and a 'peg_rev' parameter have swapped their positions in the
argument list.
In the c-header files mostly the peg_rev- comes before the rev-argument
but in the client.rb this is reversed.
This is not realy a large problem because the arguments are also swapped
in the calls to the c-functions.
Therefore the user has to call the ruby-methods like the c-functions.
The only wrong effect is the handling of the default values of the
parameters
and the wrong documentation effect.
Received on Tue Jul 25 16:43:01 2006