* Daniel Shahaf <d...@daniel.shahaf.name> [2017-05-23] > > The report says that the use-after-free occured inside the cleanup handler. > It > doesn't say where the accessed object was allocated or freed; to get that > info, > you'd have had to compile APR with pool debugging (--enable-pool-debug), then > the second and third traceback would have pointed to the site of the malloc() > and of the apr_pool_clear().
Thanks for your response! I did not make much progress: I know that --config-file option is necessary for reproduction, that actual config file is irrelevant (may be empty), and here is the ASAN report from subversion r1796426 and apr 1.6.0 with -DAPR_POOL_DEBUG=13 (I replaced path prefixes with // for convenience). > The pool cleanup is registered in add_object_ref(). Can you break in that > function and confirm which of its two callsites is involved? When I comment out `add_object_ref' in `lookup' the bug remains, but when I delete it from `insert' svnserve exits successfully. ==456372==ERROR: AddressSanitizer: heap-use-after-free on address 0x60600000ea80 at pc 0x00000097c7c9 bp 0x7fff2ae32eb0 sp 0x7fff2ae32ea8 READ of size 8 at 0x60600000ea80 thread T0 #0 0x97c7c8 in object_ref_cleanup //subversion/subversion/libsvn_subr/object_pool.c:144:45 #1 0x640010 in run_cleanups //apr/memory/unix/apr_pools.c:2629:9 #2 0x63bbb1 in pool_clear_debug //apr/memory/unix/apr_pools.c:1830:5 #3 0x63c0a8 in pool_destroy_debug //apr/memory/unix/apr_pools.c:1915:5 #4 0x63b1ed in apr_pool_destroy_debug //apr/memory/unix/apr_pools.c:1957:5 #5 0x63fdae in apr_pool_destroy //apr/memory/unix/apr_pools.c:2887:5 #6 0x5c0d15 in main //subversion/subversion/svnserve/svnserve.c:1432:3 #7 0x7f22c12d682f in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x2082f) #8 0x4f2c78 in _start (/home/orivej/bin/svnserve+0x4f2c78) 0x60600000ea80 is located 0 bytes inside of 56-byte region [0x60600000ea80,0x60600000eab8) freed by thread T0 here: #0 0x59114b in free //compiler-rt/lib/asan/asan_malloc_linux.cc:47:3 #1 0x63bf6c in pool_clear_debug //apr/memory/unix/apr_pools.c:1853:13 #2 0x63c0a8 in pool_destroy_debug //apr/memory/unix/apr_pools.c:1915:5 #3 0x63bb9c in pool_clear_debug //apr/memory/unix/apr_pools.c:1827:9 #4 0x63c0a8 in pool_destroy_debug //apr/memory/unix/apr_pools.c:1915:5 #5 0x63b1ed in apr_pool_destroy_debug //apr/memory/unix/apr_pools.c:1957:5 #6 0x63fdae in apr_pool_destroy //apr/memory/unix/apr_pools.c:2887:5 #7 0x5c0d15 in main //subversion/subversion/svnserve/svnserve.c:1432:3 #8 0x7f22c12d682f in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x2082f) previously allocated by thread T0 here: #0 0x59149c in malloc //compiler-rt/lib/asan/asan_malloc_linux.cc:64:3 #1 0x63b31b in pool_alloc //apr/memory/unix/apr_pools.c:1740:16 #2 0x63b229 in apr_palloc_debug //apr/memory/unix/apr_pools.c:1781:11 #3 0x63fd26 in apr_palloc //apr/memory/unix/apr_pools.c:2863:12 #4 0x97c214 in insert //subversion/subversion/libsvn_subr/object_pool.c:230:20 #5 0x97c0d6 in svn_object_pool__insert //subversion/subversion/libsvn_subr/object_pool.c:321:3 #6 0x8fc7b0 in find_config //subversion/subversion/libsvn_repos/config_pool.c:89:7 #7 0x8fc2dd in svn_repos__config_pool_get //subversion/subversion/libsvn_repos/config_pool.c:126:33 #8 0x5c340f in sub_main //subversion/subversion/svnserve/svnserve.c:1063:7 #9 0x5c0c1d in main //subversion/subversion/svnserve/svnserve.c:1411:9 #10 0x7f22c12d682f in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x2082f)