Using serf 1.3.x@2383 I see a SEGV after an HTTP timeout due to serf's pool cleanups accessing memory after it has been released. I have a post-commit script that takes longer than the client's http-timeout and I see this:
valgrind -q subversion/svn/.libs/lt-svn import -mm repo/format http://localhost:8888/obj/repo/f --config-option servers:global:http-timeout=5 ==3724== Invalid read of size 8 ==3724== at 0x523EFD2: handler_cleanup (util.c:1878) ==3724== by 0x4BBB3C2: run_cleanups (apr_pools.c:2352) ==3724== by 0x4BBA12A: pool_clear_debug (apr_pools.c:1553) ==3724== by 0x4BBA34D: pool_destroy_debug (apr_pools.c:1638) ==3724== by 0x4BBA10D: pool_clear_debug (apr_pools.c:1550) ==3724== by 0x4BBA34D: pool_destroy_debug (apr_pools.c:1638) ==3724== by 0x4BBA436: apr_pool_destroy_debug (apr_pools.c:1680) ==3724== by 0x42BA63: main (svn.c:3051) ==3724== Address 0x8e53490 is 0 bytes inside a block of size 56 free'd ==3724== at 0x402AF4C: free (vg_replace_malloc.c:468) ==3724== by 0x4BBA1F9: pool_clear_debug (apr_pools.c:1576) ==3724== by 0x4BBA34D: pool_destroy_debug (apr_pools.c:1638) ==3724== by 0x4BBA10D: pool_clear_debug (apr_pools.c:1550) ==3724== by 0x4BBA34D: pool_destroy_debug (apr_pools.c:1638) ==3724== by 0x4BBA10D: pool_clear_debug (apr_pools.c:1550) ==3724== by 0x4BBA34D: pool_destroy_debug (apr_pools.c:1638) ==3724== by 0x4BBA436: apr_pool_destroy_debug (apr_pools.c:1680) ==3724== by 0x42BA63: main (svn.c:3051) ==3724== ==3724== Invalid read of size 8 ==3724== at 0x64FC04D: reset_connection (outgoing.c:563) ==3724== by 0x64FD51F: serf_connection_reset (outgoing.c:1421) ==3724== by 0x523EFDC: handler_cleanup (util.c:1878) ==3724== by 0x4BBB3C2: run_cleanups (apr_pools.c:2352) ==3724== by 0x4BBA12A: pool_clear_debug (apr_pools.c:1553) ==3724== by 0x4BBA34D: pool_destroy_debug (apr_pools.c:1638) ==3724== by 0x4BBA10D: pool_clear_debug (apr_pools.c:1550) ==3724== by 0x4BBA34D: pool_destroy_debug (apr_pools.c:1638) ==3724== by 0x4BBA436: apr_pool_destroy_debug (apr_pools.c:1680) ==3724== by 0x42BA63: main (svn.c:3051) ==3724== Address 0x4141414141414141 is not stack'd, malloc'd or (recently) free'd ==3724== ==3724== ==3724== Process terminating with default action of signal 11 (SIGSEGV) ==3724== General Protection Fault ==3724== at 0x64FC04D: reset_connection (outgoing.c:563) ==3724== by 0x64FD51F: serf_connection_reset (outgoing.c:1421) ==3724== by 0x523EFDC: handler_cleanup (util.c:1878) ==3724== by 0x4BBB3C2: run_cleanups (apr_pools.c:2352) ==3724== by 0x4BBA12A: pool_clear_debug (apr_pools.c:1553) ==3724== by 0x4BBA34D: pool_destroy_debug (apr_pools.c:1638) ==3724== by 0x4BBA10D: pool_clear_debug (apr_pools.c:1550) ==3724== by 0x4BBA34D: pool_destroy_debug (apr_pools.c:1638) ==3724== by 0x4BBA436: apr_pool_destroy_debug (apr_pools.c:1680) ==3724== by 0x42BA63: main (svn.c:3051) Segmentation fault Note that I have pool debugging enabled and 0x41 is the poison byte written to memory before free. -- Philip Martin | Subversion Committer WANdisco // *Non-Stop Data*
