On Tue, Nov 26, 2013 at 12:42 PM, Branko Čibej <[email protected]> wrote:
> On 25.11.2013 17:32, [email protected] 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.
