You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Philip Martin <ph...@wandisco.com> on 2013/10/15 16:56:22 UTC
valgrind overlapping memcpy warning on log addressing branch
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*
Re: valgrind overlapping memcpy warning on log addressing branch
Posted by Philip Martin <ph...@wandisco.com>.
Philip Martin <ph...@wandisco.com> writes:
> Branko Čibej <br...@wandisco.com> writes:
>
>> Memcpy is not guaranteed to copy data in order of increasing addresses; or
>> in fact any specific order. It has to be memmove.
>
> Indeed, memmove is correct if the source and destination overlap but I'm
> not yet sure whether the bug is the overlap or the use of memcpy.
I see it's been fixed by r1532565.
--
Philip Martin | Subversion Committer
WANdisco // *Non-Stop Data*
Re: valgrind overlapping memcpy warning on log addressing branch
Posted by Philip Martin <ph...@wandisco.com>.
Branko Čibej <br...@wandisco.com> writes:
> Memcpy is not guaranteed to copy data in order of increasing addresses; or
> in fact any specific order. It has to be memmove.
Indeed, memmove is correct if the source and destination overlap but I'm
not yet sure whether the bug is the overlap or the use of memcpy.
Similar problem:
$ valgrind -q .libs/lt-prefix-string-test --cleanup
PASS: lt-prefix-string-test 1: check empty strings
==9846== Source and destination overlap in memcpy(0x41770d8, 0x41770d9, 7)
==9846== at 0x4C2A690: memcpy (mc_replace_strmem.c:838)
==9846== by 0x40A45F0: svn_prefix_string__create (prefix_string.c:222)
==9846== by 0x400CDE: test_string_creation (prefix-string-test.c:84)
==9846== by 0x402A10A: do_test_num (svn_test_main.c:271)
==9846== by 0x402AD03: main (svn_test_main.c:594)
==9846==
PASS: lt-prefix-string-test 2: create many strings
==9846== Source and destination overlap in memcpy(0x41770d8, 0x41770d9, 7)
==9846== at 0x4C2A690: memcpy (mc_replace_strmem.c:838)
==9846== by 0x40A45F0: svn_prefix_string__create (prefix_string.c:222)
==9846== by 0x400F10: test_string_comparison (prefix-string-test.c:113)
==9846== by 0x402A10A: do_test_num (svn_test_main.c:271)
==9846== by 0x402AD03: main (svn_test_main.c:594)
==9846==
PASS: lt-prefix-string-test 3: compare strings
> On 15 Oct 2013 15:57, "Philip Martin" <ph...@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*
>>
--
Philip Martin | Subversion Committer
WANdisco // *Non-Stop Data*
Re: valgrind overlapping memcpy warning on log addressing branch
Posted by Branko Čibej <br...@wandisco.com>.
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" <ph...@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*
>
Re: valgrind overlapping memcpy warning on log addressing branch
Posted by Stefan Fuhrmann <st...@wandisco.com>.
On Tue, Oct 15, 2013 at 4:56 PM, Philip Martin
<ph...@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
>
Oops. Copy'n'pasto. Fixed in /trunk and relevant branches now.
Thanks for taking the code for a spin!
-- Stefan^2.