Re: Subversion BDB doesn't work with Apache 2.4 event MPM

Philip Martin <philip.martin_at_wandisco.com> writes:

> ==10434== Thread 15:
> ==10434== Invalid read of size 4
> ==10434== at 0x802D5BB: svn_fs_bdb__open_internal (env.c:660)
> ==10434== by 0x802D679: svn_fs_bdb__open (env.c:672)
> ==10434== by 0x80390D7: open_databases (fs.c:536)
> ==10434== by 0x8039C26: base_open (fs.c:763)
> ==10434== by 0x77445A5: svn_fs_open (fs-loader.c:374)
> ==10434== by 0x752D8C6: get_repos (repos.c:1416)
> ==10434== by 0x752DA13: svn_repos_open2 (repos.c:1462)
> ==10434== by 0x72EBB1B: get_resource (repos.c:2159)
> ==10434== by 0x70B7B73: dav_get_resource (mod_dav.c:712)
> ==10434== by 0x70BC768: dav_method_options (mod_dav.c:1602)
> ==10434== by 0x70BDAE7: dav_handler (mod_dav.c:4706)
> ==10434== by 0x44BBBF: ap_run_handler (config.c:169)
> ==10434== Address 0x17a0b690 is 16 bytes inside a block of size 24 free'd
> ==10434== at 0x4C240FD: free (vg_replace_malloc.c:366)
> ==10434== by 0x802D0BF: svn_fs_bdb__close (env.c:539)
> ==10434== by 0x8038AAA: cleanup_fs (fs.c:183)
> ==10434== by 0x8038B36: cleanup_fs_apr (fs.c:289)
> ==10434== by 0x508DBCD: apr_pool_clear (apr_pools.c:2359)
> ==10434== by 0x669ADE3: process_lingering_close (event.c:1253)
> ==10434== by 0x669B987: listener_thread (event.c:1485)
> ==10434== by 0x58F18C9: start_thread (pthread_create.c:300)
> ==10434== by 0x600286C: clone (clone.S:112)

I think there is a refcount/locking bug in svn_fs_bdb__close. This code

- if (0 == --bdb_baton->error_info->refcount && bdb->pool)
- {
- svn_error_clear(bdb_baton->error_info->pending_errors);
-#if APR_HAS_THREADS
- free(bdb_baton->error_info);
- apr_threadkey_private_set(NULL, bdb->error_info);
-#endif
- }

should be inside svn_fs_bdb__close_internal protected by the
bdb_cache_lock otherwise the error_info refcount can change while
another thread is inside svn_fs_bdb__open_internal and holding the lock.

However moving the code from __close to __close_internal so it is inside
the lock doesn't stop the tests failing so there must be a second bug
somewhere.

-- 
uberSVN: Apache Subversion Made Easy
http://www.uberSVN.com