Philip Martin <philip.mar...@wandisco.com> writes: > Julian Foad <julianf...@btopenworld.com> writes: > >> which is better, but a trunk build using Serf just says: >> >>> svn: XML parsing failed: (405 Method Not Allowed) > > It's worse than that. My full valgrind build gives a SEGV, but only > after a whole slew of valgrind warnings like:
And with pool debugging enabled in serf for a bit more detail: ==14307== Invalid read of size 4 ==14307== at 0x9AEAFAF: serf_bucket_mem_free (allocator.c:223) ==14307== by 0x9AE9B83: serf_response_destroy_and_data (response_buckets.c:86) ==14307== by 0x9AE5F37: cancel_request (context.c:437) ==14307== by 0x9AE774B: serf_request_cancel (context.c:1384) ==14307== by 0x9AE736A: serf_connection_close (context.c:1249) ==14307== by 0x9AE59BC: clean_conn (context.c:184) ==14307== by 0x5E1329A: run_cleanups (apr_pools.c:2071) ==14307== by 0x5E12398: pool_clear_debug (apr_pools.c:1409) ==14307== by 0x5E12599: pool_destroy_debug (apr_pools.c:1494) ==14307== by 0x5E1237E: pool_clear_debug (apr_pools.c:1406) ==14307== by 0x5E12599: pool_destroy_debug (apr_pools.c:1494) ==14307== by 0x5E1237E: pool_clear_debug (apr_pools.c:1406) ==14307== Address 0xa8b4688 is 32 bytes inside a block of size 64 free'd ==14307== at 0x4C2130F: free (vg_replace_malloc.c:323) ==14307== by 0x5E12469: pool_clear_debug (apr_pools.c:1432) ==14307== by 0x5E12599: pool_destroy_debug (apr_pools.c:1494) ==14307== by 0x5E1237E: pool_clear_debug (apr_pools.c:1406) ==14307== by 0x5E12599: pool_destroy_debug (apr_pools.c:1494) ==14307== by 0x5E1237E: pool_clear_debug (apr_pools.c:1406) ==14307== by 0x5E12599: pool_destroy_debug (apr_pools.c:1494) ==14307== by 0x5E1237E: pool_clear_debug (apr_pools.c:1406) ==14307== by 0x5E12599: pool_destroy_debug (apr_pools.c:1494) ==14307== by 0x5E1266D: apr_pool_destroy_debug (apr_pools.c:1536) ==14307== by 0x414B27: main (main.c:2262) There is no Subversion code beyond main. Is this a serf bug, rather than a Subversion bug? I'm using serf 0.3.0. -- Philip
