Philip Martin <philip.mar...@wandisco.com> writes: > Moving update_ancestry from tree.c to dag.c is one way to fix the > problem.
This was applied in r1302613. I believe this also fixes the minfo-cnt corruption that has been observed. To reproduce apply the following patch to the old client to allow commit to be paused: Index: ../src/subversion/libsvn_fs_fs/tree.c =================================================================== --- ../src/subversion/libsvn_fs_fs/tree.c (revision 1302612) +++ ../src/subversion/libsvn_fs_fs/tree.c (working copy) @@ -1694,6 +1694,7 @@ any future merges will only be between that node and whatever the root node of the youngest rev is by then. */ err = merge_changes(NULL, youngish_root_node, txn, conflict, iterpool); + { char buf[256]; fputs("waiting...", stdout);fgets(buf, 255, stdin); } if (err) { if ((err->apr_err == SVN_ERR_FS_CONFLICT) && conflict_p) Now the scenario: svnadmin create repo svn mkdir -mm file://`pwd`/repo/{A,B,C} svn co file://`pwd`/repo wc1 svn co file://`pwd`/repo wc2 svn co file://`pwd`/repo wc3 svn ps svn:mergeinfo /P:2 wc1/A svn ps svn:mergeinfo /Q:2 wc2/B svn ps svn:mergeinfo /R:2 wc3/C Now commit wc1 using the patched client running under valgrind. At the first "waiting..." prompt commit wc2 using a standard client. Continue the first commit to get a second "waiting..." prompt and commit wc3 using a standard client. Continue the first commit and valgrind reports errors such as: ==23311== Conditional jump or move depends on uninitialised value(s) ==23311== at 0x98E0E5A: svn_fs_fs__dag_increment_mergeinfo_count (dag.c:544) ==23311== by 0x9906847: merge (tree.c:1551) ==23311== by 0x9906A18: merge_changes (tree.c:1599) ==23311== by 0x9906C06: svn_fs_fs__commit_txn (tree.c:1696) ==23311== by 0x6C8C6D9: svn_fs_commit_txn (fs-loader.c:646) ==23311== by 0x6A5B12C: svn_repos_fs_commit_txn (fs-wrap.c:59) ==23311== by 0x6A51D0E: close_edit (commit.c:693) ==23311== by 0x4E4A34F: svn_client__do_commit (commit_util.c:1898) ==23311== by 0x4E45723: svn_client_commit6 (commit.c:1689) ==23311== by 0x4097D6: svn_cl__commit (commit-cmd.c:169) ==23311== by 0x416FA1: main (main.c:2699) ==23311== Syscall param write(buf) points to uninitialised byte(s) ==23311== at 0x62CC0D0: __write_nocancel (syscall-template.S:82) ==23311== by 0x5E7D4FC: apr_file_flush_locked (readwrite.c:317) ==23311== by 0x5E7D7AF: apr_file_flush (readwrite.c:340) ==23311== by 0x5E7CFA4: apr_unix_file_cleanup (open.c:77) ==23311== by 0x59FADAF: svn_io_file_close (io.c:3092) ==23311== by 0x98E9083: svn_fs_fs__put_node_revision (fs_fs.c:2318) ==23311== by 0x98E1039: svn_fs_fs__dag_increment_mergeinfo_count (dag.c:575) ==23311== by 0x9906847: merge (tree.c:1551) ==23311== by 0x9906A18: merge_changes (tree.c:1599) ==23311== by 0x9906C06: svn_fs_fs__commit_txn (tree.c:1696) ==23311== by 0x6C8C6D9: svn_fs_commit_txn (fs-loader.c:646) ==23311== by 0x6A5B12C: svn_repos_fs_commit_txn (fs-wrap.c:59) ==23311== Address 0xb2ee1dc is 92 bytes inside a block of size 4,096 alloc'd ==23311== at 0x4C244E8: malloc (vg_replace_malloc.c:236) ==23311== by 0x5E806D0: pool_alloc (apr_pools.c:1463) ==23311== by 0x5E7CDFB: apr_file_open (open.c:211) ==23311== by 0x59F5194: file_open (io.c:280) ==23311== by 0x59FABF6: svn_io_file_open (io.c:3049) ==23311== by 0x98E8FC4: svn_fs_fs__put_node_revision (fs_fs.c:2308) ==23311== by 0x98E1039: svn_fs_fs__dag_increment_mergeinfo_count (dag.c:575) ==23311== by 0x9906847: merge (tree.c:1551) ==23311== by 0x9906A18: merge_changes (tree.c:1599) ==23311== by 0x9906C06: svn_fs_fs__commit_txn (tree.c:1696) ==23311== by 0x6C8C6D9: svn_fs_commit_txn (fs-loader.c:646) ==23311== by 0x6A5B12C: svn_repos_fs_commit_txn (fs-wrap.c:59) The commit fails because the count: is wrong, but if I disable that check to allow the commit to complete then I see a bogus minfo-cnt such as: id: 0.0.r7/322 type: dir pred: 0.0.r4/180 count: 5 text: 7 198 111 0 242bff40060f22bcf85959dcf552851a cpath: / copyroot: 0 / minfo-cnt: 43 Using the current trunk with the issue 4129 fix applied this no longer happens: I don't get the valgrind warnings and the minfo-cnt is correct. -- uberSVN: Apache Subversion Made Easy http://www.uberSVN.com