> -----Original Message-----
> From: stefan2_at_apache.org [mailto:stefan2_at_apache.org]
> Sent: vrijdag 2 mei 2014 16:08
> To: commits_at_subversion.apache.org
> Subject: svn commit: r1591919 - in /subversion/trunk/subversion: include/
> include/private/ libsvn_fs/ libsvn_fs_base/bdb/ libsvn_fs_fs/ libsvn_fs_x/
> libsvn_ra_svn/ libsvn_subr/ svnserve/ tests/ tests/libsvn_fs_fs/
>
> Author: stefan2
> Date: Fri May 2 14:07:40 2014
> New Revision: 1591919
>
> URL: http://svn.apache.org/r1591919
> Log:
> APR mutexes don't support recursive locking on all platforms.
> As a result, trying to take out the same lock twice in the
> same thread will cause a lock up under e.g. Linux. This patch
> adds an option to svn_mutex__t that detects recursive locking
> attempts in most cases and returns a proper error.
>
> The idea is simply to store the thread ID of the lock OWNER
> along the actual mutex object. If that matches the current
> thread's ID, there is a violation. As the current thread
> cannot race with itself and because any other thread uses a
> different thread ID, setting and comparing this aux. info can
> be done safely.
>
> Also, we may allow for false negatives here since we only try
> to detect code sequences that are already illegal in the first
> place. We also don't make that check mandatory as access to
> thread IDs and their comparison may be somewhat expensive on
> some systems - which would impair the futex-like behavior that
> we assume in some places like the caches.
>
> A more detailed description has been added to the source code.
> A FSFS-based test is added as that has been the origin of the
> feature request.
>
> Current users will be updated as follows. FS level locks and
> library / module initialization will enable recursion detection.
> Potentially runtime critical, internal use disables it.
>
> * subversion/include/svn_error_codes.h
> (SVN_ERR_RECURSIVE_LOCK): Define a new error code for invalid
> locking schemes.
>
> * subversion/include/private/svn_mutex.h
> (svn_mutex__t): Our mutex is now a struct as we add aux.
> data to it.
> (svn_mutex__init): Add the CHECKED option.
>
> * subversion/libsvn_subr/mutex.c
> (svn_mutex__t): Define the mutex structure and and document
> the aux. data extensively.
> (svn_mutex__init): Update constructor.
> (svn_mutex__lock): Optionally, check for recursive locking attempts
> and update the associtated aux. data.
> (svn_mutex__unlock): Optionally, update the aux. data for recursive
> lock detection.
>
> * subversion/tests/libsvn_fs_fs/fs-fs-pack-test.c
> (never_reached,
> lock_again): Callback functions required by the new test.
> (recursive_locking): New test expecting an SVN_ERR_RECURSIVE_LOCK.
> (test_funcs): Register the new test.
This new test currently causes a deadlock on Windows and a test failure on OpenBSD.
OpenBSD:
[[[
subversion/tests/libsvn_fs_fs/fs-fs-pack-test.c:1159,
subversion/libsvn_fs_fs/fs_fs.c:424,
subversion/libsvn_fs_fs/fs_fs.c:248,
subversion/libsvn_fs_fs/fs_fs.c:236,
subversion/libsvn_fs_fs/fs_fs.c:248,
subversion/libsvn_fs_fs/fs_fs.c:236,
subversion/libsvn_fs_fs/fs_fs.c:248,
subversion/libsvn_fs_fs/fs_fs.c:236,
subversion/tests/libsvn_fs_fs/fs-fs-pack-test.c:1148: (apr_err=SVN_ERR_TEST_FAILED)
svn_tests: E200006: Expected error SVN_ERR_RECURSIVE_LOCK but got SVN_NO_ERROR
FAIL: fs-fs-pack-test 15: prevent recursive locking
]]]
Windows:
Hang in
[[[
> libapr-1.dll!apr_file_lock(apr_file_t * thefile, int type) Line 35 C
fs-fs-pack-test.exe!svn_io_lock_open_file(apr_file_t * lockfile_handle, int exclusive, int nonblocking, apr_pool_t * pool) Line 2137 C
fs-fs-pack-test.exe!svn_io_file_lock2(const char * lock_file, int exclusive, int nonblocking, apr_pool_t * pool) Line 2239 C
fs-fs-pack-test.exe!get_lock_on_filesystem(const char * lock_filename, apr_pool_t * pool) Line 115 C
fs-fs-pack-test.exe!with_some_lock_file(with_lock_baton_t * baton) Line 202 C
fs-fs-pack-test.exe!with_lock(void * baton, apr_pool_t * pool) Line 248 C
fs-fs-pack-test.exe!svn_fs_fs__with_all_locks(svn_fs_t * fs, svn_error_t * (void *, apr_pool_t *) * body, void * baton, apr_pool_t * pool) Line 424 C
fs-fs-pack-test.exe!lock_again(void * baton, apr_pool_t * pool) Line 1148 C
fs-fs-pack-test.exe!with_some_lock_file(with_lock_baton_t * baton) Line 230 C
fs-fs-pack-test.exe!with_lock(void * baton, apr_pool_t * pool) Line 248 C
fs-fs-pack-test.exe!with_some_lock_file(with_lock_baton_t * baton) Line 230 C
fs-fs-pack-test.exe!with_lock(void * baton, apr_pool_t * pool) Line 248 C
fs-fs-pack-test.exe!with_some_lock_file(with_lock_baton_t * baton) Line 230 C
fs-fs-pack-test.exe!with_lock(void * baton, apr_pool_t * pool) Line 248 C
fs-fs-pack-test.exe!svn_fs_fs__with_all_locks(svn_fs_t * fs, svn_error_t * (void *, apr_pool_t *) * body, void * baton, apr_pool_t * pool) Line 424 C
fs-fs-pack-test.exe!recursive_locking(const svn_test_opts_t * opts, apr_pool_t * pool) Line 1159 C
fs-fs-pack-test.exe!test_thread(apr_thread_t * thread, void * data) Line 519 C
libapr-1.dll!dummy_worker(void * opaque) Line 79 C
]]]
Bert
Received on 2014-05-05 14:48:31 CEST