Philip Martin <[email protected]> writes: > Philip Martin <[email protected]> writes: > >> What's going on? > > The change fixes the test by causing the -r9:1 merge to be done in the > "right" way as -r8:6 then -r6:1
With r1304613 I get valgrind warnings on the failing merge: ==6510== Conditional jump or move depends on uninitialised value(s) ==6510== at 0x4E76DBC: compare_merge_source_ts (merge.c:6206) ==6510== by 0x651B809: msort_with_tmp (msort.c:84) ==6510== by 0x651BBDB: qsort_r (msort.c:298) ==6510== by 0x4E77134: combine_range_with_segments (merge.c:6306) ==6510== by 0x4E775C7: normalize_merge_sources_internal (merge.c:6469) ==6510== by 0x4E77928: normalize_merge_sources (merge.c:6562) ==6510== by 0x4E81361: merge_peg_locked (merge.c:10814) ==6510== by 0x4E8162D: svn_client_merge_peg4 (merge.c:10867) ==6510== by 0x418335: svn_cl__merge (merge-cmd.c:447) ==6510== by 0x416F91: main (main.c:2699) These go away with r1304614 but that might be false negative. If there is still a sorting problem it would explain why some buildbots PASS and some FAIL. -- uberSVN: Apache Subversion Made Easy http://www.uberSVN.com
