Your message dated Fri, 10 Jul 2026 17:43:07 +0200
with message-id
<g6npxi2i74no5axvjm6tajuangkjnoscrr67lult3hafqt5gaw@4lbntap6yovh>
and subject line Re: Bug#1093468: valgrind: False positive on overlapping
source and destination for memmove(3)
has caused the Debian Bug report #1093468,
regarding valgrind: False positive on overlapping source and destination for
memmove(3)
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)
--
1093468: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1093468
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Package: valgrind
Version: 1:3.20.0-2.1
Severity: normal
Tags: upstream patch
X-Debbugs-Cc: [email protected]
Dear Maintainer,
Doing developer testing on Samba's CTDB component and (at least) one
of its tests failed unexpectedly when running under "valgrind -q".
The code flow where valgrind reliably fails is like this:
==30742== Source and destination overlap in memcpy_chk(0x1ffefff608,
0x1ffefff602, 8)
==30742== at 0x4852152: __memcpy_chk (vg_replace_strmem.c:1746)
==30742== by 0x4C5F004: memmove (string_fortified.h:36)
==30742== by 0x4C5F004: inet_pton6 (inet_pton.c:226)
==30742== ...
This error is independent of the CTDB code, since the error is
occurring in inet_pton(3). memmove(3) is supposed to allow overlaps:
The memmove() function copies n bytes from memory area src to memory
area dest. The memory areas may overlap: [...]
... so, the valgrind failure should not occur.
I built various valgrind versions from upstream source and it appears
this was fixed/worked-around upstream between versions 3.21.0 and
3.22.0. The exact upstream commit that fixes the issues is
53e101f562fa89bbf92d658fba626e2397862a16 (hence, use of the "patch"
tag on this bug). There may be a better solution.
Upgrading valgrind in Debian to the latest stable upstream version
(3.24.0) would fix the problem.
Thanks...
peace & happiness,
martin
-- System Information:
Debian Release: trixie/sid
APT prefers testing
APT policy: (990, 'testing')
Architecture: amd64 (x86_64)
Kernel: Linux 6.12.9-rt-amd64 (SMP w/12 CPU threads; PREEMPT)
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8),
LANGUAGE=en_AU:en Shell: /bin/sh linked to /usr/bin/dash
Init: sysvinit (via /sbin/init)
LSM: AppArmor: enabled
Versions of packages valgrind depends on:
ii libc6 2.40-5
ii libc6-dbg 2.40-5
Versions of packages valgrind recommends:
ii gdb 15.2-1+b1
pn valgrind-dbg <none>
Versions of packages valgrind suggests:
pn kcachegrind <none>
pn valgrind-mpi <none>
-- no debconf information
--- End Message ---
--- Begin Message ---
Fixed around Jan the 22nd 2025.
--
PEB
Le dimanche 19 janvier 2025 à 15:48:25+1100, Martin Schwenke a écrit :
> Package: valgrind
> Version: 1:3.20.0-2.1
> Severity: normal
> Tags: upstream patch
> X-Debbugs-Cc: [email protected]
>
> Dear Maintainer,
>
> Doing developer testing on Samba's CTDB component and (at least) one
> of its tests failed unexpectedly when running under "valgrind -q".
>
> The code flow where valgrind reliably fails is like this:
>
> ==30742== Source and destination overlap in memcpy_chk(0x1ffefff608,
> 0x1ffefff602, 8)
> ==30742== at 0x4852152: __memcpy_chk (vg_replace_strmem.c:1746)
> ==30742== by 0x4C5F004: memmove (string_fortified.h:36)
> ==30742== by 0x4C5F004: inet_pton6 (inet_pton.c:226)
> ==30742== ...
>
> This error is independent of the CTDB code, since the error is
> occurring in inet_pton(3). memmove(3) is supposed to allow overlaps:
>
> The memmove() function copies n bytes from memory area src to memory
> area dest. The memory areas may overlap: [...]
>
> ... so, the valgrind failure should not occur.
>
> I built various valgrind versions from upstream source and it appears
> this was fixed/worked-around upstream between versions 3.21.0 and
> 3.22.0. The exact upstream commit that fixes the issues is
> 53e101f562fa89bbf92d658fba626e2397862a16 (hence, use of the "patch"
> tag on this bug). There may be a better solution.
>
> Upgrading valgrind in Debian to the latest stable upstream version
> (3.24.0) would fix the problem.
>
> Thanks...
>
> peace & happiness,
> martin
>
> -- System Information:
> Debian Release: trixie/sid
> APT prefers testing
> APT policy: (990, 'testing')
> Architecture: amd64 (x86_64)
>
> Kernel: Linux 6.12.9-rt-amd64 (SMP w/12 CPU threads; PREEMPT)
> Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8),
> LANGUAGE=en_AU:en Shell: /bin/sh linked to /usr/bin/dash
> Init: sysvinit (via /sbin/init)
> LSM: AppArmor: enabled
>
> Versions of packages valgrind depends on:
> ii libc6 2.40-5
> ii libc6-dbg 2.40-5
>
> Versions of packages valgrind recommends:
> ii gdb 15.2-1+b1
> pn valgrind-dbg <none>
>
> Versions of packages valgrind suggests:
> pn kcachegrind <none>
> pn valgrind-mpi <none>
>
> -- no debconf information
--
Pierre-Elliott Bécue
GPG: 9AE0 4D98 6400 E3B6 7528 F493 0D44 2664 1949 74E2
It's far easier to fight for principles than to live up to them.
signature.asc
Description: PGP signature
--- End Message ---
