"Justin Erenkrantz" <justin@erenkrantz.com> writes:
> On 12/26/06, David Glasser <glasser@mit.edu> wrote:
>> How tough would it be to be able to build svn with both ra plugins,
>> and have the choice of which to use be determined by a
>> ~/.subversion/config option (which could be tweaked on a
>> server-by-server basis (eg for Google) in ~/.subversion/servers)?
>>
>> Do the plugins actually overlap in symbols in some way?
>
> We'd have to rewrite how the RA layers work and are loaded (see
> ra_loader.c), so it's not trivial and might end up breaking our compat
> rules. Every time we've talked about this in the past, we've decided
> against changing how they work. *shrug* -- justin
Ever since serf appeared in the tree my ra_dav linked client has tried
to load ra_serf dynamically, see my original report here:
http://svn.haxx.se/dev/archive-2006-06/0767.shtml
I think that's a loader bug, although it hasn't affected me because my
system doesn't have an ra_serf library.
I have just built an ra_serf linked client and that client attempts to
load the ra_dav library dynamically. Since I do have an ra_dav library
installed this means that both ra_dav and ra_serf are present:
$ subversion/svn/svn --version | grep ra_
* ra_dav : Module for accessing a repository via WebDAV (DeltaV) protocol.
* ra_svn : Module for accessing a repository using the svn network protocol.
* ra_local : Module for accessing a repository on local disk.
* ra_serf : Access repository via WebDAV protocol through serf.
If I move my ra_dav installation so that the client doesn't find it
then I know the client must be using ra_serf. Then I get SEGVs when
using https:
(gdb) r ls https://svn.collab.net/repos/svn
Starting program: /home/pm/sw/subversion/obj/subversion/svn/.libs/lt-svn ls https://svn.collab.net/repos/svn
[Thread debugging using libthread_db enabled]
[New Thread 16384 (LWP 13160)]
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 16384 (LWP 13160)]
0x4022ae21 in apr_allocator_alloc (allocator=0x0, size=16104)
at memory/unix/apr_pools.c:196
196 if (index <= allocator->max_index) {
(gdb) bt
#0 0x4022ae21 in apr_allocator_alloc (allocator=0x0, size=16104)
at memory/unix/apr_pools.c:196
#1 0x404ee7f0 in serf_bucket_mem_alloc (allocator=0x80a07f8, size=16104)
at buckets/allocator.c:197
#2 0x404ef9cf in serf_bucket_ssl_create (ssl_ctx=0x0, allocator=0x808c828,
type=0x404f19a0) at buckets/ssl_buckets.c:443
#3 0x404efc0b in serf_bucket_ssl_decrypt_create (stream=0x80959f8,
ssl_ctx=0x0, allocator=0x808c828) at buckets/ssl_buckets.c:532
#4 0x4046a1c9 in svn_ra_serf__conn_setup (sock=0x808d930, baton=0x808c7f8,
pool=0x808c0f0) at ../svn/subversion/libsvn_ra_serf/util.c:53
#5 0x404ec7f1 in serf_context_run (ctx=0x808c3c8, duration=2000000000,
pool=0x808f228) at context.c:572
#6 0x4046a53b in svn_ra_serf__context_run_wait (done=0x808d664,
sess=0x808c040, pool=0x808f228)
at ../svn/subversion/libsvn_ra_serf/util.c:200
#7 0x40460bb6 in svn_ra_serf__wait_for_props (prop_ctx=0x808d630,
sess=0x808c040, pool=0x808f228)
at ../svn/subversion/libsvn_ra_serf/property.c:599
#8 0x40460c7f in svn_ra_serf__retrieve_props (prop_vals=0x808d5b8,
sess=0x808c040, conn=0x808c7f8, url=0x808c780 "/repos/svn", rev=-1,
depth=0x4046ffe8 "0", props=0x40471c40, pool=0x808f228)
at ../svn/subversion/libsvn_ra_serf/property.c:623
#9 0x4046bb6a in svn_ra_serf__discover_root (vcc_url=0xbffff5b4,
rel_path=0x0, session=0x808c040, conn=0x808c7f8,
orig_path=0x808c780 "/repos/svn", pool=0x808f228)
at ../svn/subversion/libsvn_ra_serf/util.c:956
#10 0x4046390b in svn_ra_serf__get_latest_revnum (ra_session=0x808bfb8,
latest_revnum=0xbffff6b8, pool=0x808f228)
at ../svn/subversion/libsvn_ra_serf/serf.c:211
#11 0x4008bf89 in svn_ra_get_latest_revnum (session=0x808bfb8,
latest_revnum=0xbffff6b8, pool=0x808f228)
at ../svn/subversion/libsvn_ra/ra_loader.c:346
#12 0x40042d7c in svn_client__get_revision_number (revnum=0xbffff6b8,
ra_session=0x808bfb8, revision=0xbffff770,
path=0x808f408 "https://svn.collab.net/repos/svn", pool=0x808f228)
at ../svn/subversion/libsvn_client/revisions.c:65
#13 0x4003fe5a in svn_client__repos_locations (start_url=0xbffff77c,
start_revision=0xbffff750, end_url=0xbffff748, end_revision=0xbffff754,
ra_session=0x808bfb8, path=0x808f408 "https://svn.collab.net/repos/svn",
revision=0xbffff770, start=0xbffff764, end=0xbffff758, ctx=0x808a8c0,
pool=0x808f228) at ../svn/subversion/libsvn_client/ra.c:769
#14 0x40040499 in svn_client__ra_session_from_path (ra_session_p=0xbffff828,
rev_p=0xbffff824, url_p=0xbffff81c,
path_or_url=0x808f408 "https://svn.collab.net/repos/svn",
peg_revision_p=0xbffff8c0, revision=0xbffffa2c, ctx=0x808a8c0,
pool=0x808f228) at ../svn/subversion/libsvn_client/ra.c:901
#15 0x40039de2 in svn_client_list (
path_or_url=0x808f408 "https://svn.collab.net/repos/svn",
peg_revision=0xbffff8c0, revision=0xbffffa2c, recurse=0, dirent_fields=1,
fetch_locks=0, list_func=0x805061c <print_dirent>, baton=0xbffff8d0,
ctx=0x808a8c0, pool=0x808f228)
at ../svn/subversion/libsvn_client/list.c:123
#16 0x08051145 in svn_cl__list (os=0x806bdc0, baton=0xbffffa1c, pool=0x806ba38)
at ../svn/subversion/svn/list-cmd.c:300
#17 0x08053aad in main (argc=3, argv=0xbffffbc4)
at ../svn/subversion/svn/main.c:1559
Some more trivial observations:
- configure doesn't treat serf and neon equally: I get warnings about
not building ra_dav, even when using --without-neon, but no
comparable warnings about not building ra_serf.
- there are a number of compiler warnings in libsvn_ra_serf to do with
unused and shadowed variables.
--
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Jan 18 03:58:04 2007