On Tue, May 6, 2014 at 12:18 AM, Stefan Fuhrmann <
> On Mon, May 5, 2014 at 2:06 PM, Stefan Sperling <stsp_at_elego.de> wrote:
>> On Fri, May 02, 2014 at 02:07:40PM -0000, stefan2_at_apache.org wrote:
>> > 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.
>> > * 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.
>> Hi Stefan,
>> This new test fails on the bb-openbsd bot.
>> Can you please look into this?
>> Note that the bot is deliberately compiling APR and everything else
>> without support for threads. Perhaps the test or other code doesn't
>> take this possibility into account?
> Since double locking attempts on the same file
> may be problem even without threading support,
> we should detect recursive mutex locks there
> as well. r1592640 may do the trick. Could not
> test it, though.
I see that it is still failing on the buildbot and I have no clue
as to why. When I hard-code APR_HAS_THREADS to 0,
the test still passes (using the alternative code path).
All I found was a consistency edge case which did not
effect the outcome of the tests. Fixed in r1592763.
Received on 2014-05-06 17:03:36 CEST