Hello,
I noticed in dmesg that in my repository svnserve occasionally crashes.
This happens at exit, so it is not visible to end users. I captured a
few sessions at the svn protocol level that resulted in a crash; client
commands are quite different in each one; sending an input that crashed
`svnserve -t` again always crashes it; I did not manage to reproduce
this in a new repository. I tested with subversion 1.9.0, 1.9.4 and
subversion trunk, apr 1.3.0 and apr 1.5.2 with the same result.
Here is the AddressSanitizer report of the problem (with subversion
1.9.4 and apr 1.3.0). For me it seems that a piece of memory belonging
to the object_pool is registered for run_cleanups in the main pool, then
right before return from main() all child pools of the main pool are
destroyed, then run_cleanups of the main pool calls object_ref_cleanup
with a pointer to a freed memory. Is this correct? How is this
supposed to work? Could you help me spot the difference between
expected and unexpected paths of code concerning the issue?
==329484==ERROR: AddressSanitizer: heap-use-after-free on address 0x6250000234d0 at pc 0x00000077f3f9 bp 0x7ffc53dac920 sp 0x7ffc53dac918
READ of size 8 at 0x6250000234d0 thread T0
#0 0x77f3f8 in object_ref_cleanup /home/orivej/src/subversion/subversion/libsvn_subr/object_pool.c:148:45
#1 0x9b7dd0 in run_cleanups /home/orivej/src/apr/memory/unix/apr_pools.c:2298:9
#2 0x9b66e4 in apr_pool_destroy /home/orivej/src/apr/memory/unix/apr_pools.c:783:5
#3 0x5bbb65 in main /home/orivej/src/subversion/subversion/svnserve/svnserve.c:1368:3
#4 0x7f59a0f5882f in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x2082f)
#5 0x4edac8 in _start (/home/orivej/bin/svnserve+0x4edac8)
0x6250000234d0 is located 976 bytes inside of 8192-byte region [0x625000023100,0x625000025100)
freed by thread T0 here:
#0 0x58bf9b in free /home/orivej/src/compiler-rt/lib/asan/asan_malloc_linux.cc:47:3
#1 0x9b5991 in allocator_free /home/orivej/src/apr/memory/unix/apr_pools.c:407:9
#2 0x9b6a4f in apr_pool_destroy /home/orivej/src/apr/memory/unix/apr_pools.c:825:5
#3 0x9b66cf in apr_pool_destroy /home/orivej/src/apr/memory/unix/apr_pools.c:780:9
#4 0x5bbb65 in main /home/orivej/src/subversion/subversion/svnserve/svnserve.c:1368:3
#5 0x7f59a0f5882f in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x2082f)
previously allocated by thread T0 here:
#0 0x58c2ec in malloc /home/orivej/src/compiler-rt/lib/asan/asan_malloc_linux.cc:64:3
#1 0x9b516e in allocator_alloc /home/orivej/src/apr/memory/unix/apr_pools.c:330:17
#2 0x9b5d5a in apr_pool_create_ex /home/orivej/src/apr/memory/unix/apr_pools.c:860:17
#3 0x62986e in svn_pool_create_ex /home/orivej/src/subversion/subversion/libsvn_subr/pool.c:70:3
#4 0x77e654 in svn_object_pool__new_wrapper_pool /home/orivej/src/subversion/subversion/libsvn_subr/object_pool.c:356:10
#5 0x6f04ae in auto_parse /home/orivej/src/subversion/subversion/libsvn_repos/config_pool.c:215:14
#6 0x6eeab1 in svn_repos__config_pool_get /home/orivej/src/subversion/subversion/libsvn_repos/config_pool.c:523:17
#7 0x5be05c in sub_main /home/orivej/src/subversion/subversion/svnserve/svnserve.c:1002:7
#8 0x5bba6d in main /home/orivej/src/subversion/subversion/svnserve/svnserve.c:1347:9
#9 0x7f59a0f5882f in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x2082f)
Received on 2017-05-23 10:21:22 CEST