Hi,
I recently stumbled upon the svnrdump crash in Subversion 1.8.1 and
Subversion@trunk around r1514208. It looks like the problem is in the way
serf works with APR pools during SSL initialization / deinitialization.
The crash can be easily reproduced by issuing the
'svnrdump dump
https://svn.apache.org' command (which coredumps in the
'apr_terminate' call) and happens with serf-1.2.1, serf-1.3.0 and serf@trunk
around r2135:
[[[
svnrdump dump
https://svn.apache.org
svnrdump: E175002: Unexpected HTTP status 405 'Method Not Allowed' on '/'
svnrdump: E175002: Additional errors:
svnrdump: E175002: PROPFIND request on '/' failed: 405 Method Not Allowed
Segmentation fault (core dumped)
]]]
Digging a bit shows that the following things happen:
1. subversion/svnrdump/svnrdump.c:main() : main()
Creates top-level APR pool (MAIN_POOL).
2. buckets/ssl_buckets.c : ssl_init_context()
Creates another top-level pool (SSL_POOL) and ALLOCATOR within this pool,
binds them to the serf_ssl_context_t CONTEXT object.
3. subversion/svnrdump/svnrdump.c:main() : main()
SSL encryption / decryption happens and memory is allocated from SSL_POOL
via ALLOCATOR.
4. subversion/svnrdump/svnrdump.c:main() : main()
Error happens and svnrdump exits without explicitly destroying the MAIN_POOL
(its destruction is postponed until apr_terminate).
5. apr_terminate()
Pools are destroyed in reverse order: SSL_POOL is destroyed before the
MAIN_POOL. MAIN_POOL destruction closes connections and bang, you're dead:
closing connections attempts to reclaim free memory using the
CONTEXT->ALLOCATOR. CONTEXT->ALLOCATOR is invalid at this moment (because
SSL_POOL is already destroyed), so this leads to a crash.
I found a way to reproduce this problem using the serf test framework, see
the attached patch. It is not something you can commit, but I guess it might
prove useful during investigation.
I've also attached two related backtraces (crash itself and the
ALLOCATOR creation) for svrdump built with APR_POOL_DEBUG.
Thanks and regards,
Evgeny Kotkov