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 2014/06/27 12:21:26 UTC
serf connection reset SEGV after timeout
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*