Memcpy is not guaranteed to copy data in order of increasing addresses; or
in fact any specific order. It has to be memmove.
On 15 Oct 2013 15:57, "Philip Martin" <philip.martin_at_wandisco.com> wrote:
> I get the following when running fs-fs-pack-test 1:
>
> ==18975== Source and destination overlap in memcpy(0x84c2190, 0x84c2191, 7)
> ==18975== at 0x4C2A690: memcpy (mc_replace_strmem.c:838)
> ==18975== by 0x412F5F0: svn_prefix_string__create (prefix_string.c:222)
> ==18975== by 0x406B138: copy_node_to_temp (pack.c:713)
> ==18975== by 0x406C3E4: pack_range (pack.c:1209)
> ==18975== by 0x406CEC1: pack_log_addressed (pack.c:1413)
> ==18975== by 0x406D6DD: pack_rev_shard (pack.c:1601)
> ==18975== by 0x406D91E: pack_shard (pack.c:1660)
> ==18975== by 0x406DF77: pack_body (pack.c:1801)
> ==18975== by 0x4057218: with_some_lock_file (fs_fs.c:184)
> ==18975== by 0x40572F0: svn_fs_fs__with_write_lock (fs_fs.c:202)
> ==18975== by 0x406E060: svn_fs_fs__pack (pack.c:1829)
> ==18975== by 0x4056B78: fs_pack (fs.c:353)
> ==18975==
> PASS: lt-fs-fs-pack-test 1: pack a FSFS filesystem
>
> --
> Philip Martin | Subversion Committer
> WANdisco // *Non-Stop Data*
>
Received on 2013-10-15 22:05:43 CEST