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

segfault in ruby bindings triggerd by config=Svn::Core::Config.config(@cfgPath)

From: Husterer, Thomas RD-CP1 <Thomas.Husterer_at_heidelberg.com>
Date: 2006-07-25 16:42:00 CEST

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
to declare the proxy's address.

collabnet = svn.collab.net
http-proxy-host = proxy
http-proxy-port = 8080

In the ruby script in the Svn::Client::Context object I read the config
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
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
#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
    option=0x0, sectionp=0xfeee0f78) at
#9 0xf6585385 in svn_config_enumerate2 (cfg=0x9325d90,
    section=0xf65b495f "groups", callback=0xf658542c <search_groups>,
    baton=0xfeee0fb0, pool=0x93bc6c0) at
#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,
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,
callbacks=0x93bc6f8, callback_baton=0x93bc718,
    config=0x932dd00, pool=0x93bc6c0) at
#13 0xf652395c in svn_client__open_ra_session_internal (
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,
", 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,
", peg_revision_p=0xfeee13a0, revision=0xfeee1390,
    ctx=0x930ebe8, pool=0x90900a8) at subversion/libsvn_client/ra.c:911
#16 0xf65209f8 in svn_client_info (
", 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
the proxy but local servers are available. This works without any

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
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
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,
+ result = (svn_error_t *)svn_config_get_config(&(arg1)->config,
+ 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.


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)


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
and the wrong documentation effect.
Received on Tue Jul 25 16:43:01 2006

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.