|
From: ISHIKAWA,chiaki <ish...@yk...> - 2022-05-11 03:10:24
|
Hi, I have been analyzing thunderbird mail client under valgrind for sometime. memcheck has been so useful for me to find memory-related errors. Thank you for releasing this great tool. Recently, I noticed an invalid read of 8 bytes warning, which should be familiar to all of us. Interestingly, the initial part of the stack trace is found in a report in Qt bug database. It comes from dynamic loading library support. https://bugreports.qt.io/browse/QTBUG-90374 It was filed last year. My system is Debian GNU/Linux and I used gcc to compile thunderbird. The report was done by someone who uses clang. I believe the issue lies in a certain version of dl-library, glibc OR valgrind? The reason I say valgrind might be to blame, too, is as follows. (Debian is known to release toolchains very conservatively. I think that is why I did not see this issue last year.) Actually, mine has line numbers slight off due to version differences I suspect. 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) 143:39.64 GECKO(115765) ==115769== by 0x4007666: _dl_dst_count (dl-load.c:251) 143:39.64 GECKO(115765) ==115769== by 0x4007857: expand_dynamic_string_token (dl-load.c:393) 143:39.64 GECKO(115765) ==115769== by 0x40079C7: fillin_rpath.isra.0 (dl-load.c:465) 143:39.68 GECKO(115765) ==115769== by 0x4007CC2: decompose_rpath (dl-load.c:636) 143:39.68 GECKO(115765) ==115769== by 0x4009E9D: cache_rpath (dl-load.c:678) 143:39.68 GECKO(115765) ==115769== by 0x4009E9D: cache_rpath (dl-load.c:659) ... [omitted] ... My local valgrind dump tells me where the address was allocated. 143:40.60 GECKO(115765) ==115769== Address 0x27ba3819 is 9 bytes inside a block of size 15 alloc'd 143:40.65 GECKO(115765) ==115769== at 0x483CF9B: malloc (vg_replace_malloc.c:380) 143:40.65 GECKO(115765) ==115769== by 0x402074B: malloc (rtld-malloc.h:56) 143:40.65 GECKO(115765) ==115769== by 0x402074B: strdup (strdup.c:42) 143:40.65 GECKO(115765) ==115769== by 0x4007C54: decompose_rpath (dl-load.c:611) 143:40.65 GECKO(115765) ==115769== by 0x4009E9D: cache_rpath (dl-load.c:678) 143:40.65 GECKO(115765) ==115769== by 0x4009E9D: cache_rpath (dl-load.c:659) 143:40.65 GECKO(115765) ==115769== by 0x4009E9D: _dl_map_object (dl-load.c:2174) 143:40.65 GECKO(115765) ==115769== by 0x400E4B0: openaux (dl-deps.c:64) ... [omission] ... I *think* this is a valid error case of large-sized READ used in strncmp reading beyond the allocated memory boundary. (strcmp.S shows 8 octets read instead of one octet at a time.) I think such a usage of strdup/str{n}cmp combination is abound in C source codes. So I thought maybe valgrind was reporting something different. Otherwise, many application programs have to create suppression for this type of issue. That is what I thought initially. A different type of error I thought initially was, say, for example, 9 bytes inside a block of size 15 might mean somehow the data contains uninitialized data in the string area in that position. However, come to think of it, if so, strdup would have triggered a valgrind warning before this. There is no warning from valgrind for strdup. Also, I created a test program and realized that in that case, valgrind prints ==120076== Conditional jump or move depends on uninitialised value(s) ==120076== at 0x4843172: strncmp (vg_replace_strmem.c:663) ==120076== by 0x108778: main (in /home/ishikawa/Dropbox/TB-DIR/a.out) So the original problem must be the read beyond malloc'ed area boundary. Now, is dl-library to blame? I think dl-library has been used literally hundreds of million times or more daily and is hard to think that there is a bug there. (Famous last word). Dl-library does not have control how long each path strings are (I think it is trying to record the path components of a loading path), and thus cannot control valgrind messages generated due to 8-char read going beyond the malloced memory end. (So probably people have to create suppression after all. If the particular version has this issue.) As for valgrind, can valgrind be somehow more intelligent in this case? Maybe creating a substitute strcmp? (I know single char comparison at a time would be slower than comparing 8 characters at a time when appropriate). But at least, this type of surprise warning would be reduced. However, we may have a problem here for glibc.. If this read beyond the malloced region is for real, we have a problem. I have no idea how this behavior is constrained or sanctioned by C standard, C library standard or POSIX standard, but the use of 8 octets strcmp.S can lead to a real issue possibly unless malloc() does allocate memory chunks in 8 or larger unit uniformly. Unless glibc makes sure that there is a guard area between malloc area and the end of user virtual space. I have an experience where a bitblt-like CPU instruction expected us to create a bitmap with a horizontal bit length of multiple of 16 (or 8?). even if the really used screen size is less than that. So we had to round it up to the multiple of 16 (or 8?). I got a bit stingy on memory use and once created a bitmap data with the raster line not appended with this extra octets to make its length a multiple of 16 (or 8). Kaboom. I created this memory area using the C runtime library of the CPU/computer maker's OS. When the CPU bitblt-like instruction accessed the last raster line data, it fetches data 16 (or 8?) octets at a time and at the end, it accessed beyond the malloced area. And it was BEYOND the allocated user memory space by the OS. (The access of 8-byte read for intermediate ratlines ended up reading the next allocated rasterline area, and so it was OK.) So the program crashed due to memory violation. It took me a couple of weeks to figure this out since bitblt-like instruction did not offer any clue regarding where the address violation occurred. Also, only one of the screen bitmaps created thusly was at the end of user virtual space and it was difficult to realize why the instruction crashed seemingly in random manner when it handled other bitmaps without a problem. The CPU vendor intended to use the instruction only for the main display screen of its work station and in that case, the memory is preallocated in neat 16-multiple horizontal. I tried to use the bitblt-like instruction for arbitrary use-defined virtual screen. So my message here is that there *can* be a grave consequence of this malloc and reading larger than originally assumed chunk behavior, but I am not sure where to report this and alert the developers. Yeah, if malloc() allocates 8 or 16 byte chunks always, it should be OK [and we are better off it is built this way due to some standard, glibc manifest, or whatever published document which won't change overnight.] Even in this age of PC users having GBs of memory, I hate to think of programs which allocates memory using 3 or 4 octet length... Chiaki |
|
From: Floyd, P. <pj...@wa...> - 2022-05-11 07:54:22
|
Hi Can you give us the source of the small reproducer the versions of Valgrind, Debian, GCC and glibc? As you mention, functions like strncmp are often optimized to work on multiple bytes at a time and to take advantage of the fact that memory will always be allocated in a multiple of say 8 or 16 bytes. And what happens sometime is that a function like strncmp will be replaced by the compiler with something like __strncmp_avx128 or something like that. If Valgrind doesn't recognize this it can't redirect it and do error checking on it. I would expect that the error message contain the name of the Valgrind redirect, for instance ==22489== at 0x4033B7C: __strncmp_sse42 (vg_replace_strmem.c:712) Si it seems to me that you have a redirection problem. For some reason Valgrind is not seeing your strncmp when the client libc gets loaded into memory. A+ Paul |
|
From: ISHIKAWA,chiaki <ish...@yk...> - 2022-05-20 07:02:08
|
Dear Paul, Thank you for your e-mail and the lucid explanation. I am sorry that I could not write to you earlier. There was something wrong with my PC hardware and it took me quite a while to re-install many software products I regularly use. I will try to create a short sample. (The whole thunderbird software is a gigantic problem.) But it may be difficult since the source code is large and if the compiler's code generation is history-sensitive, the problem may not be easy to re-create. I will also check on the versions of tools that was used when the problem was noticed. Let me have a couple of hours to check the versions. BTW, now I vaguely recall that there was an issue with DL-library released many years ago by Debian regarding the symbols for strcpy and friends. I can't recall the details now, but in that instance, the lack of proper debug symbols made the re-direction difficult(?) If my hazy memory is correct, the today's case may be influenced by a similar issue, but I better collect the versions so that someone in the know can experiment on their ends. Back then, I think I created a wrapper that introduces the symbols for strcmp and friends. But that was many years ago. TIA Chiaki PS: For those curious enough to know the hardware issue, I wanted to replace my Ryzen 1700 CPU with 16MB of L3 cache with Ryzen 3700x with 32GB of cache, solely because I learned that larger the cache, the valgrind running big program like thunderbird mail client would fare better. After a few years of use of 1700, I suspect the CPU is the limiting factor. I like it.: it uses much less power than many other modern CPUs. So it runs cool, and the PC is very silent without noisy fans. Unfortunately, when I replaced the CPUs after carefully checking BIOS version, etc. to make sure the CPU would run on the motherboard (yes, it did. It runs linux without an issue at all,), somehow Windows 10 Pro hosting my virtualbox running linux did not boot any more after the replacement and trashed my boot environment. Aargh. In the end, I figured it was faulty AMD SATA driver which got installed maybe in the last couple of years when I installed AMD's chip driver. It did not cause a problem for Ryzen 1700 for the last few years, but with 3700x, the boot fails due to it. After the boot failure, even the safe mode fails to boot. Ugh. I had to re-install windows and so had to re-install many applications and such that I use for work and hobby. Oh, such is life. But I am a happy camper now with the second hand Ryzen 3700x and hope to run and find more of these valgrind issues of TB soon. The whole build time from scratch got shorted from abot 90+ minutes to 60+ minutes. Not bad. I have yet to figure out the shortening of TB's test suite execution time. I am hampered with strange errors that I did not notice a few months before. Maybe these are newly introduced errors, including the one I reported, and I am analyzing whether I can simply suppress them or investigate in detail. On 2022/05/11 16:54, Floyd, Paul wrote: > Hi > > Can you give us > > the source of the small reproducer > > the versions of Valgrind, Debian, GCC and glibc? > > As you mention, functions like strncmp are often optimized to work on > multiple bytes at a time and to take advantage of the fact that memory > will always be allocated in a multiple of say 8 or 16 bytes. And what > happens sometime is that a function like strncmp will be replaced by > the compiler with something like __strncmp_avx128 or something like > that. If Valgrind doesn't recognize this it can't redirect it and do > error checking on it. > > I would expect that the error message contain the name of the Valgrind > redirect, for instance > > ==22489== at 0x4033B7C: __strncmp_sse42 (vg_replace_strmem.c:712) > > Si it seems to me that you have a redirection problem. For some reason > Valgrind is not seeing your strncmp when the client libc gets loaded > into memory. > > > A+ > > Paul > > > > > _______________________________________________ > Valgrind-users mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-users |
|
From: Floyd, P. <pj...@wa...> - 2022-05-20 07:58:21
|
Hi Chiaki Debugging redirection issues isn't normally too slow. Redirection is done when Valgrind loads the guest executable and libraries. Run Valgrind with --trace-redir=yes and you should see Valgrind printing what it finds in * ld.so, the link loader * the client executable * the valgrind tool * the valgrind shared lib preloads (core and tool) * any client shared libraries libc falls under the last category, though there are a small number of C functions in the link loader (memcpy, strcmp etc). You should see things like --830-- ld-linux-x86-64.so.2 strcmp RL-> (2016.0) 0x040343b0 --830-- libc.so* __strcmp_sse42 RL-> (2016.0) 0x04034370 --830-- libc.so* __strcmp_sse2 RL-> (2016.0) 0x04034330 --830-- libc.so* __GI_strcmp RL-> (2016.0) 0x040342f0 If you don't see any symbols being redirected then you have a problem. A+ Paul |
|
From: ISHIKAWA,chiaki <ish...@yk...> - 2022-05-20 15:00:38
|
Dear Paul, On 2022/05/20 16:58, Floyd, Paul wrote: > Hi Chiaki > > Debugging redirection issues isn't normally too slow. Redirection is > done when Valgrind loads the guest executable and libraries. > > Run Valgrind with --trace-redir=yes and you should see Valgrind > printing what it finds in > > * ld.so, the link loader > * the client executable > * the valgrind tool > * the valgrind shared lib preloads (core and tool) > * any client shared libraries > > libc falls under the last category, though there are a small number of > C functions in the link loader (memcpy, strcmp etc). > > You should see things like > > --830-- ld-linux-x86-64.so.2 strcmp RL-> (2016.0) 0x040343b0 > --830-- libc.so* __strcmp_sse42 RL-> (2016.0) > 0x04034370 > --830-- libc.so* __strcmp_sse2 RL-> (2016.0) > 0x04034330 > --830-- libc.so* __GI_strcmp RL-> (2016.0) > 0x040342f0 > > If you don't see any symbols being redirected then you have a problem. > > > A+ > > Paul I collected the version number info and have been running TB test suite under valgrind since this morning. That was before I read this e-mail. I will give the version number below first and see if I can run valgrind to obtain the redirection information. (The thing is the already running valgrind+thunderbird is stretching my 16GB memory linux image and I am not sure if I can start another instance of valgrind+thunderbird, or I need to bite the bullet and cancel the current run. I am afraid that the test takes close to a full day...) Anyway, let me first send this version info, and I will check to see if I can obtain the redirection info easily. Obviously, I don't seem to have the redirected symbol for strncpy in the trace. That is for sure. I do see redirection for malloc. 279:13.66 GECKO(392456) ==392459== at 0x483F7B5: malloc (vg_replace_malloc.c:381) --- version info --- Hi, Before I can figure out how to create a short reproducer, here is the version info I collected. [] Debian Version ishikawa@ip030:/NEW-SSD/NREF-COMM-CENTRAL/work-dir$ uname -a Linux ip030 5.17.0-1-amd64 #1 SMP PREEMPT Debian 5.17.3-1 (2022-04-18) x86_64 GNU/Linux [gcc-10] Used compiler. I just re-compiled the source tree using this compiler and still get the same error (trace attached at the end.) Maybe I should use a newer version, but thunderbird mail client heavily relies on mozilla source code, and newer version may encounter a compiler issues (warning or worse). ishikawa@ip030:/NEW-SSD/NREF-COMM-CENTRAL/work-dir$ gcc-10 --version gcc-10 (Debian 10.3.0-15) 10.3.0 Copyright (C) 2020 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. [glibc-a] As for glibc: I was not sure how to check for the version, but here it is. ldd --version and running libc.so as a program was something I never realized we could (!) ishikawa@ip030:/NEW-SSD/NREF-COMM-CENTRAL/work-dir$ ldd /NEW-SSD/moz-obj-dir/objdir-tb3/dist/bin/thunderbird linux-vdso.so.1 (0x00007fffa31ae000) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f4403b64000) /lib64/ld-linux-x86-64.so.2 (0x00007f4403d5d000) [glibc-b] ldd --version reports: ishikawa@ip030:/NEW-SSD/NREF-COMM-CENTRAL/work-dir$ ldd --version ldd (Debian GLIBC 2.33-7) 2.33 Copyright (C) 2021 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. Written by Roland McGrath and Ulrich Drepper. [glibc-c] I did not realize that we can "run" GLIBC libc.so file this way to obtain glibc version number. The above info all points to Debian GLIBC 2.33-7 ishikawa@ip030:/NEW-SSD/NREF-COMM-CENTRAL/work-dir$ /lib/x86_64-linux-gnu/libc.so.6 GNU C Library (Debian GLIBC 2.33-7) release release version 2.33. Copyright (C) 2021 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. Compiled by GNU CC version 10.3.0. libc ABIs: UNIQUE IFUNC ABSOLUTE For bug reporting instructions, please see: <http://www.debian.org/Bugs/>. [] Version of valgrind: valgrind --version valgrind-3.18.1 (Well, I was quite upset when I initially realized I was using valgrind-3.18.0.GIT which I installed last September, but I then verified that the bug appears with the current release, too.) [Source code] mozilla comm-central source version version is: I have added a few local mods but they don't touch the affected version. changeset: 35764:90328ce5bee2 tag: qparent fxtree: comm user: John Bieling <jo...@th...> date: Wed May 18 13:13:33 2022 +0300 summary: Bug 1732554 - Make GenericSendMessage async. r=mkmelin changeset: 35763:74a4091d1c27 [Source code] mozilla mozilla-central source version is: Again, I have added several local patches, but I did not touch the affected part (famous last words). changeset: 618071:b113470be0ad tag: qparent fxtree: central user: Mozilla Releng Treescript <rel...@mo...> date: Wed May 18 19:04:24 2022 +0000 summary: no bug - Bumping Firefox l10n changesets r=release a=l10n-bump DONTBUILD Yes thunderbird mail client uses both the browser-derived code (M-C), and mail-specific code (C-C). [] The full traceback of the reported problem. I have been running valgrind+thunderbird for quite some time since this morning. I obtained the last stack trace from basically the same errors repeated during the test suite.. (Wait, I see "279:13.65 GECKO(392456) ==392459== by 0x488D2D3: dlopen@@GLIBC_2.2.5 (dlopen.c:87)" Version 2.2.5 is not the same as the version reported for glibc. Hmm? ) 279:13.65 GECKO(392456) ==392459== Invalid read of size 8 279:13.65 GECKO(392456) ==392459== at 0x4021BF4: strncmp (strcmp.S:175) 279:13.65 GECKO(392456) ==392459== by 0x400655D: is_dst (dl-load.c:214) 279:13.65 GECKO(392456) ==392459== by 0x400771E: _dl_dst_substitute (dl-load.c:293) 279:13.65 GECKO(392456) ==392459== by 0x40079C7: fillin_rpath.isra.0 (dl-load.c:465) 279:13.65 GECKO(392456) ==392459== by 0x4007CC2: decompose_rpath (dl-load.c:636) 279:13.65 GECKO(392456) ==392459== by 0x4009E9D: cache_rpath (dl-load.c:678) 279:13.65 GECKO(392456) ==392459== by 0x4009E9D: cache_rpath (dl-load.c:659) 279:13.65 GECKO(392456) ==392459== by 0x4009E9D: _dl_map_object (dl-load.c:2174) 279:13.65 GECKO(392456) ==392459== by 0x400E4B0: openaux (dl-deps.c:64) 279:13.65 GECKO(392456) ==392459== by 0x4C0362F: _dl_catch_exception (dl-error-skeleton.c:208) 279:13.65 GECKO(392456) ==392459== by 0x400E838: _dl_map_object_deps (dl-deps.c:248) 279:13.65 GECKO(392456) ==392459== by 0x40140DF: dl_open_worker (dl-open.c:584) 279:13.65 GECKO(392456) ==392459== by 0x4C0362F: _dl_catch_exception (dl-error-skeleton.c:208) 279:13.65 GECKO(392456) ==392459== by 0x4013BF9: _dl_open (dl-open.c:858) 279:13.65 GECKO(392456) ==392459== by 0x488D247: dlopen_doit (dlopen.c:66) 279:13.65 GECKO(392456) ==392459== by 0x4C0362F: _dl_catch_exception (dl-error-skeleton.c:208) 279:13.65 GECKO(392456) ==392459== by 0x4C036EE: _dl_catch_error (dl-error-skeleton.c:227) 279:13.65 GECKO(392456) ==392459== by 0x488DA58: _dlerror_run (dlerror.c:171) 279:13.65 GECKO(392456) ==392459== by 0x488D2D3: dlopen@@GLIBC_2.2.5 (dlopen.c:87) 279:13.65 GECKO(392456) ==392459== by 0x29995389: ??? (in /usr/lib/x86_64-linux-gnu/libGLX_mesa.so.0.0.0) 279:13.65 GECKO(392456) ==392459== by 0x29995478: ??? (in /usr/lib/x86_64-linux-gnu/libGLX_mesa.so.0.0.0) 279:13.65 GECKO(392456) ==392459== by 0x299744D0: ??? (in /usr/lib/x86_64-linux-gnu/libGLX_mesa.so.0.0.0) 279:13.65 GECKO(392456) ==392459== by 0x29975DDE: ??? (in /usr/lib/x86_64-linux-gnu/libGLX_mesa.so.0.0.0) 279:13.65 GECKO(392456) ==392459== by 0x2997C347: ??? (in /usr/lib/x86_64-linux-gnu/libGLX_mesa.so.0.0.0) 279:13.65 GECKO(392456) ==392459== by 0x29978C20: ??? (in /usr/lib/x86_64-linux-gnu/libGLX_mesa.so.0.0.0) 279:13.65 GECKO(392456) ==392459== by 0x9A29B23: fQueryServerString (GLXLibrary.h:131) 279:13.65 GECKO(392456) ==392459== by 0x9A29B23: mozilla::gl::GLXLibrary::EnsureInitialized(_XDisplay*) (GLContextProviderGLX.cpp:188) 279:13.65 GECKO(392456) ==392459== by 0x9A29DCC: mozilla::gl::GLXLibrary::SupportsVideoSync(_XDisplay*) (GLContextProviderGLX.cpp:237) 279:13.65 GECKO(392456) ==392459== by 0x9D1350C: gfxPlatformGtk::CreateGlobalHardwareVsyncSource() (gfxPlatformGtk.cpp:982) 279:13.65 GECKO(392456) ==392459== by 0x9D02ABF: gfxPlatform::GetGlobalHardwareVsyncSource() (gfxPlatform.cpp:2997) 279:13.65 GECKO(392456) ==392459== by 0x9D100AC: gfxPlatform::Init() (gfxPlatform.cpp:937) 279:13.65 GECKO(392456) ==392459== by 0x9D105AF: gfxPlatform::GetPlatform() (gfxPlatform.cpp:466) 279:13.65 GECKO(392456) ==392459== by 0xD07EF73: mozilla::widget::GfxInfoBase::GetContentBackend(nsTSubstring<char16_t>&) (GfxInfoBase.cpp:1871) 279:13.65 GECKO(392456) ==392459== by 0x8BBB4B5: ??? (xptcinvoke_asm_x86_64_unix.S:101) 279:13.65 GECKO(392456) ==392459== by 0x96F0C2C: Invoke (XPCWrappedNative.cpp:1626) 279:13.65 GECKO(392456) ==392459== by 0x96F0C2C: CallMethodHelper::Call() (XPCWrappedNative.cpp:1179) 279:13.65 GECKO(392456) ==392459== by 0x96F1225: XPCWrappedNative::CallMethod(XPCCallContext&, XPCWrappedNative::CallMode) (XPCWrappedNative.cpp:1125) 279:13.65 GECKO(392456) ==392459== by 0x970AE31: GetAttribute (xpcprivate.h:1470) 279:13.65 GECKO(392456) ==392459== by 0x970AE31: XPC_WN_GetterSetter(JSContext*, unsigned int, JS::Value*) (XPCWrappedNativeJSOps.cpp:1003) 279:13.65 GECKO(392456) ==392459== by 0x1048D4DB: CallJSNative(JSContext*, bool (*)(JSContext*, unsigned int, JS::Value*), js::CallReason, JS::CallArgs const&) (Interpreter.cpp:420) 279:13.65 GECKO(392456) ==392459== by 0x104A0E8C: js::InternalCallOrConstruct(JSContext*, JS::CallArgs const&, js::MaybeConstruct, js::CallReason) (Interpreter.cpp:507) 279:13.65 GECKO(392456) ==392459== by 0x104A1676: InternalCall(JSContext*, js::AnyInvokeArgs const&, js::CallReason) (Interpreter.cpp:574) 279:13.65 GECKO(392456) ==392459== by 0x104A188C: js::Call(JSContext*, JS::Handle<JS::Value>, JS::Handle<JS::Value>, js::AnyInvokeArgs const&, JS::MutableHandle<JS::Value>, js::CallReason) (Interpreter.cpp:605) 279:13.65 GECKO(392456) ==392459== by 0x104A1C96: js::CallGetter(JSContext*, JS::Handle<JS::Value>, JS::Handle<JS::Value>, JS::MutableHandle<JS::Value>) (Interpreter.cpp:731) 279:13.65 GECKO(392456) ==392459== by 0xF5FB359: CallGetter(JSContext*, JS::Handle<js::NativeObject*>, JS::Handle<JS::Value>, JS::Handle<JS::PropertyKey>, js::PropertyInfoBase<unsigned int>, JS::MutableHandle<JS::Value>) (NativeObject.cpp:1983) 279:13.65 GECKO(392456) ==392459== by 0xF5FB674: bool GetExistingProperty<(js::AllowGC)1>(JSContext*, js::MaybeRooted<JS::Value, (js::AllowGC)1>::HandleType, js::MaybeRooted<js::NativeObject*, (js::AllowGC)1>::HandleType, js::MaybeRooted<JS::PropertyKey, (js::AllowGC)1>::HandleType, js::PropertyInfoBase<unsigned int>, js::MaybeRooted<JS::Value, (js::AllowGC)1>::MutableHandleType) (NativeObject.cpp:2011) 279:13.65 GECKO(392456) ==392459== by 0xF609DB6: bool NativeGetPropertyInline<(js::AllowGC)1>(JSContext*, js::MaybeRooted<js::NativeObject*, (js::AllowGC)1>::HandleType, js::MaybeRooted<JS::Value, (js::AllowGC)1>::HandleType, js::MaybeRooted<JS::PropertyKey, (js::AllowGC)1>::HandleType, IsNameLookup, js::MaybeRooted<JS::Value, (js::AllowGC)1>::MutableHandleType) (NativeObject.cpp:2153) 279:13.65 GECKO(392456) ==392459== by 0xF60A448: js::NativeGetProperty(JSContext*, JS::Handle<js::NativeObject*>, JS::Handle<JS::Value>, JS::Handle<JS::PropertyKey>, JS::MutableHandle<JS::Value>) (NativeObject.cpp:2184) 279:13.65 GECKO(392456) ==392459== by 0xF4000DE: js::GetProperty(JSContext*, JS::Handle<JSObject*>, JS::Handle<JS::Value>, JS::Handle<JS::PropertyKey>, JS::MutableHandle<JS::Value>) (ObjectOperations-inl.h:120) 279:13.65 GECKO(392456) ==392459== by 0x1048B9BB: js::GetObjectElementOperation(JSContext*, JSOp, JS::Handle<JSObject*>, JS::Handle<JS::Value>, JS::Handle<JS::Value>, JS::MutableHandle<JS::Value>) (Interpreter-inl.h:412) 279:13.66 GECKO(392456) ==392459== by 0x10490F5E: js::GetElementOperationWithStackIndex(JSContext*, JS::Handle<JS::Value>, int, JS::Handle<JS::Value>, JS::MutableHandle<JS::Value>) (Interpreter-inl.h:509) 279:13.66 GECKO(392456) ==392459== by 0x1049900D: Interpret(JSContext*, js::RunState&) (Interpreter.cpp:3119) 279:13.66 GECKO(392456) ==392459== by 0x104A064B: js::RunScript(JSContext*, js::RunState&) (Interpreter.cpp:389) 279:13.66 GECKO(392456) ==392459== by 0x104A1385: js::InternalCallOrConstruct(JSContext*, JS::CallArgs const&, js::MaybeConstruct, js::CallReason) (Interpreter.cpp:539) 279:13.66 GECKO(392456) ==392459== by 0x104A1676: InternalCall(JSContext*, js::AnyInvokeArgs const&, js::CallReason) (Interpreter.cpp:574) 279:13.66 GECKO(392456) ==392459== Address 0x29f24919 is 9 bytes inside a block of size 15 alloc'd 279:13.66 GECKO(392456) ==392459== at 0x483F7B5: malloc (vg_replace_malloc.c:381) 279:13.66 GECKO(392456) ==392459== by 0x402074B: malloc (rtld-malloc.h:56) 279:13.66 GECKO(392456) ==392459== by 0x402074B: strdup (strdup.c:42) 279:13.66 GECKO(392456) ==392459== by 0x4007C54: decompose_rpath (dl-load.c:611) 279:13.66 GECKO(392456) ==392459== by 0x4009E9D: cache_rpath (dl-load.c:678) 279:13.66 GECKO(392456) ==392459== by 0x4009E9D: cache_rpath (dl-load.c:659) 279:13.66 GECKO(392456) ==392459== by 0x4009E9D: _dl_map_object (dl-load.c:2174) 279:13.66 GECKO(392456) ==392459== by 0x400E4B0: openaux (dl-deps.c:64) 279:13.66 GECKO(392456) ==392459== by 0x4C0362F: _dl_catch_exception (dl-error-skeleton.c:208) 279:13.66 GECKO(392456) ==392459== by 0x400E838: _dl_map_object_deps (dl-deps.c:248) 279:13.66 GECKO(392456) ==392459== by 0x40140DF: dl_open_worker (dl-open.c:584) 279:13.66 GECKO(392456) ==392459== by 0x4C0362F: _dl_catch_exception (dl-error-skeleton.c:208) 279:13.66 GECKO(392456) ==392459== by 0x4013BF9: _dl_open (dl-open.c:858) 279:13.66 GECKO(392456) ==392459== by 0x488D247: dlopen_doit (dlopen.c:66) 279:13.66 GECKO(392456) ==392459== by 0x4C0362F: _dl_catch_exception (dl-error-skeleton.c:208) 279:13.66 GECKO(392456) ==392459== by 0x4C036EE: _dl_catch_error (dl-error-skeleton.c:227) 279:13.66 GECKO(392456) ==392459== by 0x488DA58: _dlerror_run (dlerror.c:171) 279:13.66 GECKO(392456) ==392459== by 0x488D2D3: dlopen@@GLIBC_2.2.5 (dlopen.c:87) 279:13.66 GECKO(392456) ==392459== by 0x29995389: ??? (in /usr/lib/x86_64-linux-gnu/libGLX_mesa.so.0.0.0) 279:13.66 GECKO(392456) ==392459== by 0x29995478: ??? (in /usr/lib/x86_64-linux-gnu/libGLX_mesa.so.0.0.0) 279:13.66 GECKO(392456) ==392459== by 0x299744D0: ??? (in /usr/lib/x86_64-linux-gnu/libGLX_mesa.so.0.0.0) 279:13.66 GECKO(392456) ==392459== by 0x29975DDE: ??? (in /usr/lib/x86_64-linux-gnu/libGLX_mesa.so.0.0.0) 279:13.66 GECKO(392456) ==392459== by 0x2997C347: ??? (in /usr/lib/x86_64-linux-gnu/libGLX_mesa.so.0.0.0) 279:13.66 GECKO(392456) ==392459== by 0x29978C20: ??? (in /usr/lib/x86_64-linux-gnu/libGLX_mesa.so.0.0.0) 279:13.66 GECKO(392456) ==392459== by 0x9A29B23: fQueryServerString (GLXLibrary.h:131) 279:13.66 GECKO(392456) ==392459== by 0x9A29B23: mozilla::gl::GLXLibrary::EnsureInitialized(_XDisplay*) (GLContextProviderGLX.cpp:188) 279:13.66 GECKO(392456) ==392459== by 0x9A29DCC: mozilla::gl::GLXLibrary::SupportsVideoSync(_XDisplay*) (GLContextProviderGLX.cpp:237) 279:13.66 GECKO(392456) ==392459== by 0x9D1350C: gfxPlatformGtk::CreateGlobalHardwareVsyncSource() (gfxPlatformGtk.cpp:982) 279:13.66 GECKO(392456) ==392459== by 0x9D02ABF: gfxPlatform::GetGlobalHardwareVsyncSource() (gfxPlatform.cpp:2997) 279:13.66 GECKO(392456) ==392459== by 0x9D100AC: gfxPlatform::Init() (gfxPlatform.cpp:937) 279:13.66 GECKO(392456) ==392459== by 0x9D105AF: gfxPlatform::GetPlatform() (gfxPlatform.cpp:466) 279:13.66 GECKO(392456) ==392459== by 0xD07EF73: mozilla::widget::GfxInfoBase::GetContentBackend(nsTSubstring<char16_t>&) (GfxInfoBase.cpp:1871) 279:13.66 GECKO(392456) ==392459== by 0x8BBB4B5: ??? (xptcinvoke_asm_x86_64_unix.S:101) 279:13.66 GECKO(392456) ==392459== by 0x96F0C2C: Invoke (XPCWrappedNative.cpp:1626) 279:13.66 GECKO(392456) ==392459== by 0x96F0C2C: CallMethodHelper::Call() (XPCWrappedNative.cpp:1179) 279:13.66 GECKO(392456) ==392459== by 0x96F1225: XPCWrappedNative::CallMethod(XPCCallContext&, XPCWrappedNative::CallMode) (XPCWrappedNative.cpp:1125) 279:13.66 GECKO(392456) ==392459== by 0x970AE31: GetAttribute (xpcprivate.h:1470) 279:13.66 GECKO(392456) ==392459== by 0x970AE31: XPC_WN_GetterSetter(JSContext*, unsigned int, JS::Value*) (XPCWrappedNativeJSOps.cpp:1003) 279:13.66 GECKO(392456) ==392459== by 0x1048D4DB: CallJSNative(JSContext*, bool (*)(JSContext*, unsigned int, JS::Value*), js::CallReason, JS::CallArgs const&) (Interpreter.cpp:420) 279:13.66 GECKO(392456) ==392459== by 0x104A0E8C: js::InternalCallOrConstruct(JSContext*, JS::CallArgs const&, js::MaybeConstruct, js::CallReason) (Interpreter.cpp:507) 279:13.66 GECKO(392456) ==392459== by 0x104A1676: InternalCall(JSContext*, js::AnyInvokeArgs const&, js::CallReason) (Interpreter.cpp:574) 279:13.66 GECKO(392456) ==392459== by 0x104A188C: js::Call(JSContext*, JS::Handle<JS::Value>, JS::Handle<JS::Value>, js::AnyInvokeArgs const&, JS::MutableHandle<JS::Value>, js::CallReason) (Interpreter.cpp:605) 279:13.66 GECKO(392456) ==392459== by 0x104A1C96: js::CallGetter(JSContext*, JS::Handle<JS::Value>, JS::Handle<JS::Value>, JS::MutableHandle<JS::Value>) (Interpreter.cpp:731) 279:13.66 GECKO(392456) ==392459== by 0xF5FB359: CallGetter(JSContext*, JS::Handle<js::NativeObject*>, JS::Handle<JS::Value>, JS::Handle<JS::PropertyKey>, js::PropertyInfoBase<unsigned int>, JS::MutableHandle<JS::Value>) (NativeObject.cpp:1983) 279:13.66 GECKO(392456) ==392459== by 0xF5FB674: bool GetExistingProperty<(js::AllowGC)1>(JSContext*, js::MaybeRooted<JS::Value, (js::AllowGC)1>::HandleType, js::MaybeRooted<js::NativeObject*, (js::AllowGC)1>::HandleType, js::MaybeRooted<JS::PropertyKey, (js::AllowGC)1>::HandleType, js::PropertyInfoBase<unsigned int>, js::MaybeRooted<JS::Value, (js::AllowGC)1>::MutableHandleType) (NativeObject.cpp:2011) 279:13.66 GECKO(392456) ==392459== by 0xF609DB6: bool NativeGetPropertyInline<(js::AllowGC)1>(JSContext*, js::MaybeRooted<js::NativeObject*, (js::AllowGC)1>::HandleType, js::MaybeRooted<JS::Value, (js::AllowGC)1>::HandleType, js::MaybeRooted<JS::PropertyKey, (js::AllowGC)1>::HandleType, IsNameLookup, js::MaybeRooted<JS::Value, (js::AllowGC)1>::MutableHandleType) (NativeObject.cpp:2153) 279:13.67 GECKO(392456) ==392459== by 0xF60A448: js::NativeGetProperty(JSContext*, JS::Handle<js::NativeObject*>, JS::Handle<JS::Value>, JS::Handle<JS::PropertyKey>, JS::MutableHandle<JS::Value>) (NativeObject.cpp:2184) 279:13.67 GECKO(392456) ==392459== by 0xF4000DE: js::GetProperty(JSContext*, JS::Handle<JSObject*>, JS::Handle<JS::Value>, JS::Handle<JS::PropertyKey>, JS::MutableHandle<JS::Value>) (ObjectOperations-inl.h:120) 279:13.67 GECKO(392456) ==392459== by 0x1048B9BB: js::GetObjectElementOperation(JSContext*, JSOp, JS::Handle<JSObject*>, JS::Handle<JS::Value>, JS::Handle<JS::Value>, JS::MutableHandle<JS::Value>) (Interpreter-inl.h:412) 279:13.67 GECKO(392456) ==392459== by 0x10490F5E: js::GetElementOperationWithStackIndex(JSContext*, JS::Handle<JS::Value>, int, JS::Handle<JS::Value>, JS::MutableHandle<JS::Value>) (Interpreter-inl.h:509) 279:13.67 GECKO(392456) ==392459== by 0x1049900D: Interpret(JSContext*, js::RunState&) (Interpreter.cpp:3119) 279:13.67 GECKO(392456) ==392459== by 0x104A064B: js::RunScript(JSContext*, js::RunState&) (Interpreter.cpp:389) 279:13.67 GECKO(392456) ==392459== by 0x104A1385: js::InternalCallOrConstruct(JSContext*, JS::CallArgs const&, js::MaybeConstruct, js::CallReason) (Interpreter.cpp:539) 279:13.67 GECKO(392456) ==392459== by 0x104A1676: InternalCall(JSContext*, js::AnyInvokeArgs const&, js::CallReason) (Interpreter.cpp:574) 279:13.67 GECKO(392456) ==392459== by 0x104A188C: js::Call(JSContext*, JS::Handle<JS::Value>, JS::Handle<JS::Value>, js::AnyInvokeArgs const&, JS::MutableHandle<JS::Value>, js::CallReason) (Interpreter.cpp:605) 279:13.67 GECKO(392456) ==392459== by 0xF497661: JS_CallFunctionValue(JSContext*, JS::Handle<JSObject*>, JS::Handle<JS::Value>, JS::HandleValueArray const&, JS::MutableHandle<JS::Value>) (CallAndConstruct.cpp:53) [end of memo] |
|
From: John R. <jr...@bi...> - 2022-05-20 15:57:26
|
> (Wait, I see "279:13.65 GECKO(392456) ==392459== by 0x488D2D3: dlopen@@GLIBC_2.2.5 (dlopen.c:87)" > Version 2.2.5 is not the same as the version reported for glibc. Hmm? ) The "@@GLIBC_2.2.5" is the linking symbol version assigned by glibc. This effectively is an ABI version, and the ABI for dlopen has not changed for many years, even though other parts of glibc have changed; one recent release is glibc-2.33. The real key to Chiaki's problem is: > 279:13.65 GECKO(392456) ==392459== Invalid read of size 8 > 279:13.65 GECKO(392456) ==392459== at 0x4021BF4: strncmp (strcmp.S:175) which says that this 'strncmp' was not re-directed by valgrind. Re-running valgrind with the additional command-line parameter "--trace-redir=yes" will help provide more information. Probably the run can be stopped after the first actual dlopen, because that should be enough to trigger all the redirections that matter here. |
|
From: ISHIKAWA,chiaki <ish...@yk...> - 2022-05-20 17:15:17
|
Hi, 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. TIA Chiaki On 2022/05/21 0:57, John Reiser wrote: >> (Wait, I see "279:13.65 GECKO(392456) ==392459== by 0x488D2D3: >> dlopen@@GLIBC_2.2.5 (dlopen.c:87)" >> Version 2.2.5 is not the same as the version reported for glibc. Hmm? ) > > The "@@GLIBC_2.2.5" is the linking symbol version assigned by glibc. > This effectively is an ABI version, and the ABI for dlopen > has not changed for many years, even though other parts of > glibc have changed; one recent release is glibc-2.33. > > The real key to Chiaki's problem is: >> 279:13.65 GECKO(392456) ==392459== Invalid read of size 8 >> 279:13.65 GECKO(392456) ==392459== at 0x4021BF4: strncmp >> (strcmp.S:175) > which says that this 'strncmp' was not re-directed by valgrind. > Re-running valgrind with the additional command-line parameter > "--trace-redir=yes" will help provide more information. > Probably the run can be stopped after the first actual dlopen, > because that should be enough to trigger all the redirections > that matter here. > > > _______________________________________________ > Valgrind-users mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-users |
|
From: John R. <jr...@bi...> - 2022-05-21 09:42:35
|
> 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 $ |
|
From: John R. <jr...@bi...> - 2022-05-21 09:57:58
|
> This indicates that 'strncmp' should be re-directed from ld-linux-x86-64.so.2: That was done already in valgrind-3.19.0. The user problem was reported against: ----- ==4295== Memcheck, a memory error detector ==4295== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al. ==4295== Using Valgrind-3.18.1-42b08ed5bd-20211015 and LibVEX; rerun with -h for copyright info ----- which probably does not contain the fix: $ git blame shared/vg_replace_strmem.c 947388eb04 (Mike Crowe 2019-09-09 14:16:16 +0100 713) STRNCMP(VG_Z_LD_LINUX_SO_2, strncmp) 947388eb04 (Mike Crowe 2019-09-09 14:16:16 +0100 714) STRNCMP(VG_Z_LD_LINUX_X86_64_SO_2, strncmp) |
|
From: Mark W. <ma...@kl...> - 2022-05-21 10:15:45
|
Hi,
On Sat, May 21, 2022 at 02:42:22AM -0700, John Reiser wrote:
> > 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)
This looks like https://bugs.kde.org/show_bug.cgi?id=434764
iconv_open causes ld.so v2.28+ to use optimised strncmp
Which was recently (but after 3.19.0) fixed by merging this commit:
commit 947388eb043ea1c44b37df94046e1eee790ad776
Author: Mike Crowe <ma...@mc...>
AuthorDate: Mon Sep 9 14:16:16 2019 +0100
Commit: Mark Wielaard <ma...@kl...>
CommitDate: Sat May 14 00:41:18 2022 +0200
Intercept strncmp for glibc ld.so v2.28+
In glibc 5aad5f617892e75d91d4c8fb7594ff35b610c042 (first released in
v2.28) a call to strncmp was added to dl-load.c:is_dst. This causes
valgrind to complain about glibc's highly-optimised strncmp performing
sixteen-byte reads on short strings in ld.so. Let's intercept strncmp in
ld.so too so we use valgrind's simple version to avoid this problem.
Cheers,
Mark
|
|
From: John R. <jr...@bi...> - 2022-05-21 10:13:39
|
> This looks like https://bugs.kde.org/show_bug.cgi?id=434764 > iconv_open causes ld.so v2.28+ to use optimised strncmp > > Which was recently (but after 3.19.0) fixed by merging this commit: > > commit 947388eb043ea1c44b37df94046e1eee790ad776 > Author: Mike Crowe <ma...@mc...> > AuthorDate: Mon Sep 9 14:16:16 2019 +0100 > Commit: Mark Wielaard <ma...@kl...> > CommitDate: Sat May 14 00:41:18 2022 +0200 > > Intercept strncmp for glibc ld.so v2.28+ > The C standard claims that all function names that begin with 'str' or 'mem' are reserved, and that language processors (compilers, valgrind, ...) may assume that such names designate the Standard functions. If so, then valgrind's interception code is too picky about the context for re-directing these functions; just use STRNCMP("*", strncmp) etc. to re-direct them all. |
|
From: ISHIKAWA,chiaki <ish...@yk...> - 2022-05-24 04:26:52
|
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 > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-users > |