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

Re: Serf as default DAV client?

From: C. Michael Pilato <cmpilato_at_collab.net>
Date: 2007-06-11 20:36:12 CEST

Eric Gillespie wrote:
> Whatever happened to making serf the default DAV layer in 1.5? Last i
> heard, we were going to follow fsfs in this respect. fsfs was an option
> in 1.1 and the default in 1.2. Serf was an option in 1.4, shouldn't we
> make it the default now?
>
> If we don't switch to serf, it's never going to get the kind of attention
> it needs...

Inspired by this mail, I've tried to get serf going on over here instead of
neon.

I ran quickly into a bug in serfmake, which Justin kindly fixed.

That allowed me to get a build of Subversion for which serf was activated.
I can checkout, update, and commit with this client. But import segfaults,
and that's keeping me from even running the test suite. Here's a stack trace.

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1215985984 (LWP 23247)]
0xb7a01c7e in apr_allocator_free (allocator=0x41414141, node=0x809f898)
    at memory/unix/apr_pools.c:319
(gdb) where
#0 0xb7a01c7e in apr_allocator_free (allocator=0x41414141, node=0x809f898)
    at memory/unix/apr_pools.c:319
#1 0xb7d37c6b in serf_bucket_mem_free (allocator=0x809b588, block=0x809f8b8)
    at buckets/allocator.c:238
#2 0xb7d3660c in serf_default_destroy_and_data (bucket=0x809b7f8)
    at buckets/buckets.c:117
#3 0xb7d36e63 in serf_response_destroy_and_data (bucket=0x809b7f8)
    at buckets/response_buckets.c:96
#4 0xb7d34515 in cancel_request (request=0x80953b8, list=0x8092b64,
    notify_request=<value optimized out>) at ./context.c:368
#5 0xb7d34778 in serf_connection_close (conn=0x8092b30) at ./context.c:1019
#6 0xb7d56592 in svn_ra_serf__cleanup_serf_session (data=0x8091370)
    at subversion/libsvn_ra_serf/util.c:143
#7 0xb7a02878 in pool_clear_debug (pool=0x8091420,
    file_line=<value optimized out>) at memory/unix/apr_pools.c:2034
#8 0xb7a02b47 in pool_destroy_debug (pool=0x8091420,
    file_line=0xb7ee2cfc "subversion/libsvn_client/commit.c:690")
    at memory/unix/apr_pools.c:1457
#9 0xb7a02851 in pool_clear_debug (pool=0x8090dd8,
    file_line=0xb7ee2cfc "subversion/libsvn_client/commit.c:690")
    at memory/unix/apr_pools.c:1369
#10 0xb7a02c74 in apr_pool_clear_debug (pool=0x8090dd8,
    file_line=0xb7ee2cfc "subversion/libsvn_client/commit.c:690")
    at memory/unix/apr_pools.c:1432
#11 0xb7ebc2eb in svn_client_import2 (commit_info_p=0xbfcc7d00,
    path=0x80909f0 "",
    url=0x8090a60 "http://svn.collab.net/tests/repos/serf-import-1",
    nonrecursive=0, no_ignore=0, ctx=0x80757c0, pool=0x8074bc8)
    at subversion/libsvn_client/commit.c:690
#12 0x0804f297 in svn_cl__import (os=0x8074f50, baton=0xbfcc7f08,
    pool=0x8074bc8) at subversion/svn/import-cmd.c:115
#13 0x080549b7 in main (argc=6, argv=0xbfcc8024) at subversion/svn/main.c:1689

-- 
C. Michael Pilato <cmpilato@collab.net>
CollabNet   <>   www.collab.net   <>   Distributed Development On Demand

Received on Mon Jun 11 20:36:31 2007

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.