You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Philip Martin <ph...@wandisco.com> on 2010/02/05 11:23:41 UTC
ra_serf pool cleanup SEGV
Julian Foad <ju...@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:
$ valgrind -q subversion/svn/.libs/lt-svn ls http://svn.collab.net/repos/svn/trunk/COMMITTERS
svn: XML parsing failed: (405 Method Not Allowed)
==3696== Invalid read of size 4
==3696== at 0x9AEAF2A: serf_bucket_mem_free (in /usr/local/serf/lib/libserf-0.so.0.0.0)
==3696== by 0x9AE9AF3: serf_response_destroy_and_data (in /usr/local/serf/lib/libserf-0.so.0.0.0)
==3696== by 0x9AE5EC0: cancel_request (in /usr/local/serf/lib/libserf-0.so.0.0.0)
==3696== by 0x9AE76BD: serf_request_cancel (in /usr/local/serf/lib/libserf-0.so.0.0.0)
==3696== by 0x9AE72DC: serf_connection_close (in /usr/local/serf/lib/libserf-0.so.0.0.0)
==3696== by 0x9AE594C: clean_conn (in /usr/local/serf/lib/libserf-0.so.0.0.0)
==3696== by 0x5E1329A: run_cleanups (apr_pools.c:2071)
==3696== by 0x5E12398: pool_clear_debug (apr_pools.c:1409)
==3696== by 0x5E12599: pool_destroy_debug (apr_pools.c:1494)
==3696== by 0x5E1237E: pool_clear_debug (apr_pools.c:1406)
==3696== by 0x5E12599: pool_destroy_debug (apr_pools.c:1494)
==3696== by 0x5E1237E: pool_clear_debug (apr_pools.c:1406)
==3696== Address 0xa8b4688 is 32 bytes inside a block of size 64 free'd
==3696== at 0x4C2130F: free (vg_replace_malloc.c:323)
==3696== by 0x5E12469: pool_clear_debug (apr_pools.c:1432)
==3696== by 0x5E12599: pool_destroy_debug (apr_pools.c:1494)
==3696== by 0x5E1237E: pool_clear_debug (apr_pools.c:1406)
==3696== by 0x5E12599: pool_destroy_debug (apr_pools.c:1494)
==3696== by 0x5E1237E: pool_clear_debug (apr_pools.c:1406)
==3696== by 0x5E12599: pool_destroy_debug (apr_pools.c:1494)
==3696== by 0x5E1237E: pool_clear_debug (apr_pools.c:1406)
==3696== by 0x5E12599: pool_destroy_debug (apr_pools.c:1494)
==3696== by 0x5E1266D: apr_pool_destroy_debug (apr_pools.c:1536)
==3696== by 0x414B27: main (main.c:2262)
==3696==
==3696== Invalid write of size 4
==3696== at 0x9AEAF34: serf_bucket_mem_free (in /usr/local/serf/lib/libserf-0.so.0.0.0)
==3696== by 0x9AE9AF3: serf_response_destroy_and_data (in /usr/local/serf/lib/libserf-0.so.0.0.0)
==3696== by 0x9AE5EC0: cancel_request (in /usr/local/serf/lib/libserf-0.so.0.0.0)
==3696== by 0x9AE76BD: serf_request_cancel (in /usr/local/serf/lib/libserf-0.so.0.0.0)
==3696== by 0x9AE72DC: serf_connection_close (in /usr/local/serf/lib/libserf-0.so.0.0.0)
==3696== by 0x9AE594C: clean_conn (in /usr/local/serf/lib/libserf-0.so.0.0.0)
==3696== by 0x5E1329A: run_cleanups (apr_pools.c:2071)
==3696== by 0x5E12398: pool_clear_debug (apr_pools.c:1409)
==3696== by 0x5E12599: pool_destroy_debug (apr_pools.c:1494)
==3696== by 0x5E1237E: pool_clear_debug (apr_pools.c:1406)
==3696== by 0x5E12599: pool_destroy_debug (apr_pools.c:1494)
==3696== by 0x5E1237E: pool_clear_debug (apr_pools.c:1406)
==3696== Address 0xa8b4688 is 32 bytes inside a block of size 64 free'd
==3696== at 0x4C2130F: free (vg_replace_malloc.c:323)
==3696== by 0x5E12469: pool_clear_debug (apr_pools.c:1432)
==3696== by 0x5E12599: pool_destroy_debug (apr_pools.c:1494)
==3696== by 0x5E1237E: pool_clear_debug (apr_pools.c:1406)
==3696== by 0x5E12599: pool_destroy_debug (apr_pools.c:1494)
==3696== by 0x5E1237E: pool_clear_debug (apr_pools.c:1406)
==3696== by 0x5E12599: pool_destroy_debug (apr_pools.c:1494)
==3696== by 0x5E1237E: pool_clear_debug (apr_pools.c:1406)
==3696== by 0x5E12599: pool_destroy_debug (apr_pools.c:1494)
==3696== by 0x5E1266D: apr_pool_destroy_debug (apr_pools.c:1536)
==3696== by 0x414B27: main (main.c:2262)
--
Philip
Re: ra_serf pool cleanup SEGV
Posted by Philip Martin <ph...@wandisco.com>.
Philip Martin <ph...@wandisco.com> writes:
> Julian Foad <ju...@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