John, Paul, and Mark
Thank you for the information.
Debian is a bit slow in updating tools. It is very conservative.
Eventually, I obtained the valgrind git code.
(Debian is a bit slow in updating tools. It is very conservative.)
It contained the following.
#if defined(VGO_linux)
STRNCMP(VG_Z_LIBC_SONAME, strncmp)
STRNCMP(VG_Z_LIBC_SONAME, __GI_strncmp)
STRNCMP(VG_Z_LIBC_SONAME, __strncmp_sse2)
STRNCMP(VG_Z_LIBC_SONAME, __strncmp_sse42)
STRNCMP(VG_Z_LD_LINUX_SO_2, strncmp) <---
STRNCMP(VG_Z_LD_LINUX_X86_64_SO_2, strncmp) <---
#elif defined(VGO_freebsd)
For now, with this version, I no longer get the warning for strncmp.
As I looked for the false-positive warning in the new log,
I have caught a real issue of my patch for thunderbird mail client.
It was caused by slowdown by valgrind.
This was not quite intentional, but it is surely helpful to simulate
abnormal condition
to trigger unforeseen uncaught error situations.
The test is still running.
Hopefully no more error related issues.
BTW, it seemed the timing of valgrind has changed from 18.0.
$ valgrind --version
valgrind-3.20.0.GIT
I mean valgrind may take a bit longer ? to simulate the program
execution. (I am not sure. All I can is
the elapsed time seems different. It may be related to the fact that
false positive tracedump for strncmp is not printed any more, etc.)
I probably need to tweak time out values during the test.
It could be that I was not testing many smaller tests due to time out
but did not realize it because
I was focused on real memory errors reported by valgrind.
Thank you again.
Chiaki
On 2022/05/21 18:42, John Reiser wrote:
I sent a log of redirect information to both Paul and John since the
log was too large was mailing list.
I wonder what would be the preferred public sharing site for such a
purpose these days.
The preferred way is to create a bug report, attach the large file to
the bug report,
then post the URL of the bug report in a message to the mailing list.
Begin at https://valgrind.org/ . In the left nav, click on "Bug
Reports", and follow
the directions on the resulting page.
143:39.43 GECKO(115765) ==115769== Invalid read of size 8
143:39.64 GECKO(115765) ==115769== at 0x4021BF4: strncmp
(strcmp.S:175)
143:39.64 GECKO(115765) ==115769== by 0x400655D: is_dst
(dl-load.c:214)
This indicates that 'strncmp' should be re-directed from
ld-linux-x86-64.so.2:
=====
diff --git a/shared/vg_replace_strmem.c b/shared/vg_replace_strmem.c
index 3b42b3a87..8272a3ae7 100644
--- a/shared/vg_replace_strmem.c
+++ b/shared/vg_replace_strmem.c
@@ -710,6 +710,7 @@ static inline void my_exit ( int x )
STRNCMP(VG_Z_LIBC_SONAME, __GI_strncmp)
STRNCMP(VG_Z_LIBC_SONAME, __strncmp_sse2)
STRNCMP(VG_Z_LIBC_SONAME, __strncmp_sse42)
+ STRNCMP("ld-linux*.so*", strncmp)
#elif defined(VGO_freebsd)
STRNCMP(VG_Z_LIBC_SONAME, strncmp)
=====
For instance, such a change is relevant to glibc-2.33-21.fc34.x86_64:
$ readelf --all /lib64/ld-linux-x86-64.so.2 | grep strncmp
1706: 0000000000022d30 6233 FUNC LOCAL DEFAULT 13 strncmp
$
_______________________________________________
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users
_______________________________________________
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users
