Philip Martin <philip.martin_at_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
Received on 2012-03-23 20:59:08 CET