I'm seeing test failures when building Subversion and APR with pool debugging:
FAIL: lt-fs-fs-pack-test 13: upgrade txns to log addressing in shared FSFS FAIL: lt-fs-fs-pack-test 14: upgrade txns started before svnadmin upgrade FAIL: lt-fs-test 33: test dir prop preservation in unordered txns FAIL: lt-fs-test 43: test merge directory properties Valgrind reports are typically: $ valgrind -q .libs/lt-fs-test --cleanup 33 ==32655== Invalid read of size 1 ==32655== at 0x402EA79: bcmp (mc_replace_strmem.c:935) ==32655== by 0x41F6E72: find_entry (apr_hash.c:280) ==32655== by 0x41F719D: apr_hash_set (apr_hash.c:357) ==32655== by 0x50430CB: read_dir_entries (cached_data.c:2053) ==32655== by 0x50432A4: get_dir_contents (cached_data.c:2098) ==32655== by 0x5043640: svn_fs_fs__rep_contents_dir (cached_data.c:2195) ==32655== by 0x50714B3: write_final_rev (transaction.c:2897) ==32655== by 0x5074113: commit_body (transaction.c:3839) ==32655== by 0x504A898: with_some_lock_file (fs_fs.c:185) ==32655== by 0x504A970: svn_fs_fs__with_write_lock (fs_fs.c:203) ==32655== by 0x5074BB1: svn_fs_fs__commit (transaction.c:4009) ==32655== by 0x507983F: svn_fs_fs__commit_txn (tree.c:2228) ==32655== Address 0x870d120 is 0 bytes inside a block of size 2 free'd ==32655== at 0x402AF4C: free (vg_replace_malloc.c:468) ==32655== by 0x42021F9: pool_clear_debug (apr_pools.c:1576) ==32655== by 0x42022D9: apr_pool_clear_debug (apr_pools.c:1613) ==32655== by 0x5042DCC: read_dir_entries (cached_data.c:1993) ==32655== by 0x50432A4: get_dir_contents (cached_data.c:2098) ==32655== by 0x5043640: svn_fs_fs__rep_contents_dir (cached_data.c:2195) ==32655== by 0x50714B3: write_final_rev (transaction.c:2897) ==32655== by 0x5074113: commit_body (transaction.c:3839) ==32655== by 0x504A898: with_some_lock_file (fs_fs.c:185) ==32655== by 0x504A970: svn_fs_fs__with_write_lock (fs_fs.c:203) ==32655== by 0x5074BB1: svn_fs_fs__commit (transaction.c:4009) ==32655== by 0x507983F: svn_fs_fs__commit_txn (tree.c:2228) I think this was caused by r1554711, switch directory rep to array order, but I haven't identified the exact problem yet. -- Philip Martin | Subversion Committer WANdisco // *Non-Stop Data*
