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

Re: ra_serf now passes all tests was Re: svn commit: r22796 - trunk/subversion/tests/cmdline

From: Philip Martin <philip_at_codematters.co.uk>
Date: 2007-01-18 03:57:44 CET

"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:
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

This is an archived mail posted to the Subversion Dev mailing list.