Hi Chris,
even after a close look at the GNU APL code I can't see anything
wrong with how realpath() is being called.
To me it looks more like a bug in glibc 2.3, although the valgrind
message suggests that this bug causes no harm
(a memory area is copied to itself, which is an overlap but one
that causes no harm).
It also looks to me as if you are using an older GNU APL
version because I cannot
find the line in Libpath.cc that you quote below in the current GNU
APL code.
Thank you nevertheless for reporting this.
/// Jürgen
On 06/24/2018 02:29 PM, Chris Moller
wrote:
Doing some other stuff involving libapl.so, I
was running valgrind against my own code when this popped up:
==14122== Source and destination overlap in mempcpy(0x778a9e1,
0x778a9e1, 4)
==14122== at 0x4C34FF0: mempcpy (vg_replace_strmem.c:1524)
==14122== by 0x7E06634: realpath@@GLIBC_2.3
(in /usr/lib64/libc-2.27.so)
==14122== by 0x7441092: LibPaths::search_APL_lib_root()
(LibPaths.cc:186)
==14122== by 0x7441173: LibPaths::init(char const*, bool)
(LibPaths.cc:53)
==14122== by 0x7422B96: init_1(char const*, bool)
(Common.cc:77)
==14122== by 0x7509C09: init_libapl (libapl.cc:435)
==14122== by 0x4048F9: main (gapl.c:685)
The line in LibPaths.cc is:
unused = realpath(APL_lib_root, APL_lib_root);
which could obviously cause a collision.
I don't know if this is a real problem or not, but I thought I
ought to mention it to someone.
Chris Moller
|
signature.asc
Description: OpenPGP digital signature
