On Tue, Nov 26, 2013 at 12:42 PM, Branko Čibej <brane_at_wandisco.com> wrote:
> On 25.11.2013 17:32, stefan2_at_apache.org wrote:
>
> Author: stefan2
> Date: Mon Nov 25 16:32:52 2013
> New Revision: 1545338
>
> URL: http://svn.apache.org/r1545338
> Log:
> * subversion/tests/libsvn_client/client-test.c
> subversion/tests/libsvn_fs/fs-test.c
> subversion/tests/libsvn_fs/locks-test.c
> (test_funcs): Move particularly expensive tests to the top of the
> list to maximize parallism. None of these test lists
> imply a specific "simply-to-complex" ordering.
>
>
> You have a pool cleanup bug in the --parallel C tests mode. After these
> last two commits:
>
Hm. I don't see these problems here nor on our Windows
buildbot (at least svn-windows-local runs in parallel mode).
Valgrind did not show any problem either.
$ make check PARALLEL=1
> ...
> At least one test FAILED, checking /Volumes/build-trunk-amalgamated/tests.log
> FAIL: client-test: Unknown test failure; see tests.log.
> FAIL: crypto-test: Unknown test failure; see tests.log.
> FAIL: db-test: Unknown test failure; see tests.log.
> FAIL: diff-diff3-test: Unknown test failure; see tests.log.
> FAIL: entries-compat-test: Unknown test failure; see tests.log.
> FAIL: fs-fs-pack-test: Unknown test failure; see tests.log.
> FAIL: fs-test: Unknown test failure; see tests.log.
> FAIL: fs-x-pack-test: Unknown test failure; see tests.log.
> FAIL: io-test: Unknown test failure; see tests.log.
> FAIL: locks-test: Unknown test failure; see tests.log.
> FAIL: op-depth-test: Unknown test failure; see tests.log.
> FAIL: pristine-store-test: Unknown test failure; see tests.log.
> FAIL: repos-test: Unknown test failure; see tests.log.
> FAIL: string-table-test: Unknown test failure; see tests.log.
> FAIL: translate-test: Unknown test failure; see tests.log.
> FAIL: wc-test: Unknown test failure; see tests.log.
> FAIL: changes-test: Unknown test failure; see tests.log.
> FAIL: fs-base-test: Unknown test failure; see tests.log.
> FAIL: strings-reps-test: Unknown test failure; see tests.log.
>
> So, all threaded tests fail, i.e. any fix should be reproducible
on your system.
Here's the example of what tests.log has to say about these failures:
>
> changes-test(16390,0x7fff7d921180) malloc: *** error for object 0x7fc251011800: pointer being freed was not allocated
> *** set a breakpoint in malloc_error_break to debug
>
> And this is what the debugger says:
>
> $ glibtool --mode=execute lldb -- subversion/tests/libsvn_clit-test --parallel
> Current executable set to 'subversion/tests/libsvn_client/.libs/client-test' (x86_64).
> (lldb) break set -n malloc_error_break
> Breakpoint 1: where = libsystem_c.dylib`malloc_error_break, address = 0x000000000002c584
> (lldb) r
> Process 16518 launched: '/Users/brane/src/svn/build/trunk-amalgamated/subversion/tests/libsvn_client/.libs/client-test' (x86_64)
> PASS: client-test 1: test svn_client__elide_mergeinfo_catalog
> PASS: client-test 2: test svn_client_args_to_target_array
> PASS: client-test 5: test svn_client_patch
> PASS: client-test 4: test foreign repository copy
> PASS: client-test 6: test a crash in svn_client_copy5
> PASS: client-test 3: test svn_wc_add3 scenarios
> PASS: client-test 7: test youngest_common_ancestor
> client-test(16518,0x100d04000) malloc: *** error for object 0x101800000: pointer being freed was not allocated
> *** set a breakpoint in malloc_error_break to debug
> Process 16518 stopped
> * thread #2: tid = 0x5aaea9, 0x00000001008c60a0 libapr-1.0.dylib`apr_pool_destroy + 143, stop reason = EXC_BAD_ACCESS (code=1, address=0x1010a1a0)
> frame #0: 0x00000001008c60a0 libapr-1.0.dylib`apr_pool_destroy + 143
> libapr-1.0.dylib`apr_pool_destroy + 143:
> -> 0x1008c60a0: movq $0, (%rax)
> 0x1008c60a7: cmpq %rbx, 24(%r14)
> 0x1008c60ab: jne 0x1008c60b5 ; apr_pool_destroy + 164
> 0x1008c60ad: movq $0, 16(%r14)
> thread #4: tid = 0x5aaeab, 0x00000001008c60a0 libapr-1.0.dylib`apr_pool_destroy + 143, stop reason = EXC_BAD_ACCESS (code=EXC_I386_GPFLT)
> frame #0: 0x00000001008c60a0 libapr-1.0.dylib`apr_pool_destroy + 143
> libapr-1.0.dylib`apr_pool_destroy + 143:
> -> 0x1008c60a0: movq $0, (%rax)
> 0x1008c60a7: cmpq %rbx, 24(%r14)
> 0x1008c60ab: jne 0x1008c60b5 ; apr_pool_destroy + 164
> 0x1008c60ad: movq $0, 16(%r14)
> (lldb) bt
> * thread #2: tid = 0x5aaea9, 0x00000001008c60a0 libapr-1.0.dylib`apr_pool_destroy + 143, stop reason = EXC_BAD_ACCESS (code=1, address=0x1010a1a0)
> frame #0: 0x00000001008c60a0 libapr-1.0.dylib`apr_pool_destroy + 143
> frame #1: 0x00000001008cf875 libapr-1.0.dylib`apr_thread_exit + 15
> frame #2: 0x00000001008a5256 libaprutil-1.0.dylib`___lldb_unnamed_function66$$libaprutil-1.0.dylib + 842
> frame #3: 0x00007fff8d932772 libsystem_c.dylib`_pthread_start + 327
> frame #4: 0x00007fff8d91f1a1 libsystem_c.dylib`thread_start + 13
>
> Hm. So, this happens after all tests completed. I tried some
fix in r1545634 but Philip just told me that it did not help.
-- Stefan^2.
Received on 2013-11-26 13:42:48 CET