SUMMARY valgrind --tool=massif produces wrong behaviour in C++ std::string::find(char) STEPS TO REPRODUCE Create a file eg test.cpp with the following content: #include <string> #include <iostream> int main() { std::string s = "haystack"; std::cout << s.find('x', 0) << std::endl; std::cout << s.find("x", 0) << std::endl; } Compile it: g++ test.cpp Run it as follows: ./a.out valgrind ./a.out valgrind --tool=massif ./a.out OBSERVED RESULT We expect std::string::npos aka the unsigned interpretation of -1, because the character is not contained in the string. But if massif is enabled, the character is suddenly reported as present: ~$ ./a.out 18446744073709551615 18446744073709551615 ~$ valgrind -q ./a.out 18446744073709551615 18446744073709551615 ~$ valgrind --tool=massif -q ./a.out 0 18446744073709551615 EXPECTED RESULT ~$ ./a.out 18446744073709551615 18446744073709551615 ~$ valgrind -q ./a.out 18446744073709551615 18446744073709551615 ~$ valgrind --tool=massif -q ./a.out 18446744073709551615 18446744073709551615 SOFTWARE/OS VERSIONS OS: Oracle Linux 9 uname -a: Linux localhost.localdomain 5.15.0-101.103.2.1.el9uek.x86_64 #2 SMP Tue May 2 01:10:45 PDT 2023 x86_64 x86_64 x86_64 GNU/Linux g++: gcc version 11.3.1 20221121 (Red Hat 11.3.1-4.3.0.1) (GCC) valgrind-3.19.0
This is indeed strange. My guess is that std::string::find uses strpbrk. Memcheck replaces strpbrk but massif doesn’t. After that I can only imagine that there may be a bug in the vex emulation of whatever avx instruction the glibc implementation(s) use.
Looking at basic_string.tcc from https://github.com/gcc-mirror/gcc/blob/releases/gcc-11/libstdc%2B%2B-v3/include/bits/basic_string.tcc I found that: - find(char) uses __gnu_cxx::char_traits<char>::find - find(const char*) uses __gnu_cxx::char_traits<char>::find for the first character, followed by __gnu_cxx::char_traits<char>::compare to check all characters to match. In the specialization for char_traits<char>, these are implemented (https://github.com/gcc-mirror/gcc/blob/releases/gcc-11/libstdc%2B%2B-v3/include/bits/char_traits.h#L413) as: find() with __builtin_memchr, compare() with __builtin_memcmp. I checked with clang and it gives the same result: ~ $ clang++ test.cpp ~ $ ./a.out 18446744073709551615 18446744073709551615 ~ $ valgrind -q ./a.out 18446744073709551615 18446744073709551615 ~ $ valgrind -q --tool=massif ./a.out 0 18446744073709551615 ~ $ clang --version clang version 15.0.7 (Red Hat 15.0.7-2.0.1.el9) Target: x86_64-redhat-linux-gnu Thread model: posix InstalledDir: /usr/bin ~ $
On FreeBSD (clang++ with libc++ and g++ with libstdc++) it seems to work OK.
3.19.0 is a pretty old version, have you tried with 3.23.0? It seems to work fine here (Fedora 40 on x86_64).
It seems that the behaviour of __builtin_memchr depends on where the source string is stored. The following two programs have different output with massif, but otherwise the same output: Always says 0 (= not found): #include <string> #include <iostream> int main() { std::cout << (void*) __builtin_memchr("haystack", 'x', 1) << std::endl; } Says 0 normally, but 0x1fff000120 (a heap address?) with massif: #include <string> #include <iostream> int main() { std::string s = "haystack"; std::cout << (void*) __builtin_memchr(s.c_str(), 'x', 1) << std::endl; } But it looks like the same happens on the stack, massif returns 0x1fff000147 here again, but normal run returns 0: #include <string> #include <iostream> int main() { char sample[] = { 'h', 'a', 'y', 's', 't', 'a', 'c', 'k', 0 }; std::cout << (void*) __builtin_memchr(sample, 'x', 1) << std::endl; } However, just making sample a const char works: #include <string> #include <iostream> int main() { const char sample[] = { 'h', 'a', 'y', 's', 't', 'a', 'c', 'k', 0 }; std::cout << (void*) __builtin_memchr(sample, 'x', 1) << std::endl; } ~ $ ./a.out 0 ~ $ valgrind -q --tool=massif ./a.out 0
(In reply to Mark Wielaard from comment #4) > 3.19.0 is a pretty old version, have you tried with 3.23.0? > It seems to work fine here (Fedora 40 on x86_64). Can reproduce the issue with 3.20.0: #include <iostream> int main() { char sample[] = { 'h', 'a', 'y', 's', 't', 'a', 'c', 'k', 0 }; std::cout << (void*) __builtin_memchr(sample, 'x', 1) << std::endl; } ~ $ ./a.out 0 ~ $ valgrind -q --tool=massif ./a.out 0x1fff000147 ~ $ valgrind --version valgrind-3.20.0 Versions 3.21+ I cannot easily try because I don't have GLIBC 2.38. I would need to setup a virtual machine first.
Can you build Valgrind from source? It doesn't have any glic dependencies.
(In reply to martin.lueck from comment #5) > Says 0 normally, but 0x1fff000120 (a heap address?) with massif: String literals like "haystack" generally either get put into rodata (an ELF segment in the bibary file that getss mmap'd) or sometimes stored as immediate data in instructions. In this case it looks like rodata. I've tried to reproduce on Linux (Rocky 8.9 and a few combinations of GCC and Valgrind) but it always worked.
(In reply to Paul Floyd from comment #7) > Can you build Valgrind from source? It doesn't have any glic dependencies. I rebuilt it from the Fedora 40/update sources, but it still fails on my machine if the char array is non-const, i.e. it still reports a false positive that the character is found in the string. ~ $ valgrind --version valgrind-3.23.0 ~ $ g++ --version g++ (GCC) 11.3.1 20221121 (Red Hat 11.3.1-4.3.0.1) 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. ~ $ cat test.cpp #include <iostream> int main() { const char sample[] = { 'h', 0 }; std::cout << (void*) __builtin_memchr(sample, 'x', 1) << std::endl; } ~ $ g++ test.cpp -o ./a.out ~ $ ./a.out 0 ~ $ valgrind -q --tool=massif ./a.out 0 ~ $ cat test2.cpp #include <iostream> int main() { char sample[] = { 'h', 0 }; std::cout << (void*) __builtin_memchr(sample, 'x', 1) << std::endl; } ~ $ g++ test2.cpp -o ./a.out ~ $ ./a.out 0 ~ $ valgrind -q --tool=massif ./a.out 0x1fff00014e
With Fedora 40, GCC 14.2.1 and glibc 2.39 I still have no problem with tests2. objdump --disassemble=main test2 gives me 0000000000401156 <main>: 401156: 55 push %rbp 401157: 48 89 e5 mov %rsp,%rbp 40115a: 48 83 ec 10 sub $0x10,%rsp 40115e: 66 c7 45 fe 68 00 movw $0x68,-0x2(%rbp) 401164: 48 8d 45 fe lea -0x2(%rbp),%rax 401168: ba 01 00 00 00 mov $0x1,%edx 40116d: be 78 00 00 00 mov $0x78,%esi 401172: 48 89 c7 mov %rax,%rdi 401175: e8 e6 fe ff ff call 401060 <memchr@plt> 40117a: 48 89 c6 mov %rax,%rsi 40117d: bf 40 40 40 00 mov $0x404040,%edi 401182: e8 b9 fe ff ff call 401040 <_ZNSolsEPKv@plt> 401187: be 30 10 40 00 mov $0x401030,%esi 40118c: 48 89 c7 mov %rax,%rdi 40118f: e8 bc fe ff ff call 401050 <_ZNSolsEPFRSoS_E@plt> 401194: b8 00 00 00 00 mov $0x0,%eax 401199: c9 leave 40119a: c3 ret memchr is an ifunc and on my old system it's resolving to __memchr_sse2. Can you tell which version your system is using? (I used GDB and step inst (si) / next inst (ni) until I reached the memchr implementation).
I was now able to set up a Fedora 40 VM. Still reproducible: user@fedora:~$ uname -a Linux fedora 6.8.5-301.fc40.x86_64 #1 SMP PREEMPT_DYNAMIC Thu Apr 11 20:00:10 UTC 2024 x86_64 GNU/Linux user@fedora:~$ valgrind --version valgrind-3.23.0 user@fedora:~$ g++ --version g++ (GCC) 14.2.1 20240801 (Red Hat 14.2.1-1) Copyright (C) 2024 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. user@fedora:~$ cat test2.cpp #include <cstring> #include <iostream> int main() { char sample[] = { 'h', 0 }; std::cout << (void*) __builtin_memchr(sample, 'x', 1) << std::endl; } user@fedora:~$ g++ test2.cpp -o a.out user@fedora:~$ ./a.out 0 user@fedora:~$ valgrind -q --tool=massif ./a.out 0x1ffefffe6e Objdump seems to give the exact same disassembly, except some call addresses in the PLT: ~ $ objdump --disassemble=main a.out a.out: file format elf64-x86-64 Disassembly of section .init: Disassembly of section .plt: Disassembly of section .text: 0000000000401186 <main>: 401186: 55 push %rbp 401187: 48 89 e5 mov %rsp,%rbp 40118a: 48 83 ec 10 sub $0x10,%rsp 40118e: 66 c7 45 fe 68 00 movw $0x68,-0x2(%rbp) 401194: 48 8d 45 fe lea -0x2(%rbp),%rax 401198: ba 01 00 00 00 mov $0x1,%edx 40119d: be 78 00 00 00 mov $0x78,%esi 4011a2: 48 89 c7 mov %rax,%rdi 4011a5: e8 c6 fe ff ff callq 401070 <memchr@plt> 4011aa: 48 89 c6 mov %rax,%rsi 4011ad: bf 80 40 40 00 mov $0x404080,%edi 4011b2: e8 89 fe ff ff callq 401040 <_ZNSolsEPKv@plt> 4011b7: be 30 10 40 00 mov $0x401030,%esi 4011bc: 48 89 c7 mov %rax,%rdi 4011bf: e8 9c fe ff ff callq 401060 <_ZNSolsEPFRSoS_E@plt> 4011c4: b8 00 00 00 00 mov $0x0,%eax 4011c9: c9 leaveq 4011ca: c3 retq Disassembly of section .fini: When I step through with gdb (without valgrind), then on either a memchr or __builtin_memchr call it goes to _dl_lookup_symbol_x("memchr"). Afterwards, it jumsp to memchr_ifunc in /lib64/libc.so.6 and then into __memchr_sse2. So, no luck. Leaving out the -q flag shows that valgrind seems to produce less output in the erroneous case for some reason: user@fedora:~$ valgrind ./a.out ==6590== Memcheck, a memory error detector ==6590== Copyright (C) 2002-2024, and GNU GPL'd, by Julian Seward et al. ==6590== Using Valgrind-3.23.0 and LibVEX; rerun with -h for copyright info ==6590== Command: ./a.out ==6590== 0 ==6590== ==6590== HEAP SUMMARY: ==6590== in use at exit: 0 bytes in 0 blocks ==6590== total heap usage: 2 allocs, 2 frees, 74,752 bytes allocated ==6590== ==6590== All heap blocks were freed -- no leaks are possible ==6590== ==6590== For lists of detected and suppressed errors, rerun with: -s ==6590== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0) user@fedora:~$ valgrind --tool=massif ./a.out ==6602== Massif, a heap profiler ==6602== Copyright (C) 2003-2024, and GNU GPL'd, by Nicholas Nethercote et al. ==6602== Using Valgrind-3.23.0 and LibVEX; rerun with -h for copyright info ==6602== Command: ./a.out ==6602== 0x1ffefffe6e ==6602==
Also, not sure if it is relevant, but all tries before were also on a Linux VM, not native, in VirtualBox 6.50. I run native Windows 10. CPU is Intel Core i7-9700.
Please ignore my comment about the different output of valgrind. This is obviously because the first run is with memcheck and the second with massif.
Very odd. On an almost identical Fedora 40 setup both ./a.out and valgrind -q --tool=massif ./a.out simply return 0 (as they should) for the memchr example. Could you run with valgrind -v and see which architecture cpu flags it detects. Locally I get: Arch and hwcaps: AMD64, LittleEndian, amd64-cx16-lzcnt-rdtscp-sse3-ssse3-avx-avx2-bmi-f16c-rdrand-rdseed-fma
(In reply to Mark Wielaard from comment #14) > Very odd. On an almost identical Fedora 40 setup both ./a.out and valgrind > -q --tool=massif ./a.out simply return 0 (as they should) for the memchr > example. > > Could you run with valgrind -v and see which architecture cpu flags it > detects. Locally I get: > > Arch and hwcaps: AMD64, LittleEndian, > amd64-cx16-lzcnt-rdtscp-sse3-ssse3-avx-avx2-bmi-f16c-rdrand-rdseed-fma I got fewer flags, which might be because of virtualbox: amd64-cx16-lzcnt-rdtscp-sse3-ssse3-avx-avx2-rdrand-rdseed The missing ones are bmi, f16c and fma. Full output: $ valgrind -v --tool=massif ./a.out ==3264== Massif, a heap profiler ==3264== Copyright (C) 2003-2024, and GNU GPL'd, by Nicholas Nethercote et al. ==3264== Using Valgrind-3.23.0-c54d316124-20240426 and LibVEX; rerun with -h for copyright info ==3264== Command: ./a.out ==3264== --3264-- Valgrind options: --3264-- -v --3264-- --tool=massif --3264-- Contents of /proc/version: --3264-- Linux version 6.8.5-301.fc40.x86_64 (mockbuild@0bc0cc78c12e4762acf61c209bd02e96) (gcc (GCC) 14.0.1 20240328 (Red Hat 14.0.1-0), GNU ld version 2.41-34.fc40) #1 SMP PREEMPT_DYNAMIC Thu Apr 11 20:00:10 UTC 2024 --3264-- --3264-- Arch and hwcaps: AMD64, LittleEndian, amd64-cx16-lzcnt-rdtscp-sse3-ssse3-avx-avx2-rdrand-rdseed --3264-- Page sizes: currently 4096, max supported 4096 --3264-- Valgrind library directory: /usr/libexec/valgrind --3264-- Massif: alloc-fns: --3264-- Massif: malloc --3264-- Massif: __builtin_new --3264-- Massif: operator new(unsigned long) --3264-- Massif: __builtin_vec_new --3264-- Massif: operator new[](unsigned long) --3264-- Massif: calloc --3264-- Massif: aligned_alloc --3264-- Massif: realloc --3264-- Massif: memalign --3264-- Massif: posix_memalign --3264-- Massif: valloc --3264-- Massif: operator new(unsigned long, std::nothrow_t const&) --3264-- Massif: operator new[](unsigned long, std::nothrow_t const&) --3264-- Massif: operator new(unsigned long, std::align_val_t) --3264-- Massif: operator new[](unsigned long, std::align_val_t) --3264-- Massif: operator new(unsigned long, std::align_val_t, std::nothrow_t const&) --3264-- Massif: operator new[](unsigned long, std::align_val_t, std::nothrow_t const&) --3264-- Massif: ignore-fns: --3264-- Massif: <empty> --3264-- Reading syms from /home/user/a.out --3264-- Reading syms from /usr/lib64/ld-linux-x86-64.so.2 --3264-- Reading syms from /usr/libexec/valgrind/massif-amd64-linux --3264-- object doesn't have a dynamic symbol table --3264-- Scheduler: using generic scheduler lock implementation. ==3264== embedded gdbserver: reading from /tmp/vgdb-pipe-from-vgdb-to-3264-by-user-on-fedora ==3264== embedded gdbserver: writing to /tmp/vgdb-pipe-to-vgdb-from-3264-by-user-on-fedora ==3264== embedded gdbserver: shared mem /tmp/vgdb-pipe-shared-mem-vgdb-3264-by-user-on-fedora ==3264== ==3264== TO CONTROL THIS PROCESS USING vgdb (which you probably ==3264== don't want to do, unless you know exactly what you're doing, ==3264== or are doing some strange experiment): ==3264== /usr/libexec/valgrind/../../bin/vgdb --pid=3264 ...command... ==3264== ==3264== TO DEBUG THIS PROCESS USING GDB: start GDB like this ==3264== /path/to/gdb ./a.out ==3264== and then give GDB the following command ==3264== target remote | /usr/libexec/valgrind/../../bin/vgdb --pid=3264 ==3264== --pid is optional if only one valgrind process is running ==3264== --3264-- Reading syms from /usr/libexec/valgrind/vgpreload_core-amd64-linux.so --3264-- Reading syms from /usr/libexec/valgrind/vgpreload_massif-amd64-linux.so --3264-- Reading syms from /usr/lib64/libstdc++.so.6.0.33 --3264-- Reading syms from /usr/lib64/libm.so.6 --3264-- Reading syms from /usr/lib64/libgcc_s-14-20240801.so.1 --3264-- Reading syms from /usr/lib64/libc.so.6 ==3264== Downloading debug info for /usr/lib64/libc.so.6... ==3264== Server query failed: No such file or directory --3264-- REDIR: 0x4c7ddd0 (libc.so.6:malloc) redirected to 0x4841780 (malloc) ==3264== Downloading debug info for /usr/lib64/libstdc++.so.6.0.33... ==3264== Server query failed: No such file or directory --3264-- Warning: cross-CU LIMITATION: some inlined fn names --3264-- might be shown as UnknownInlinedFun ==3264== Downloading debug info for /home/user/a.out... ==3264== Server query failed: No such file or directory 0x1ffefffe6e --3264-- REDIR: 0x4c7e4d0 (libc.so.6:free) redirected to 0x4844aa1 (free) ==3264==
I ran more tests on different systems. Native Linux installation (Fedora 40) on my laptop: No issue with valgrind 3.23, g++ 14.2.1, GLIBC 2.41 Stone-age CentOS 7 inside Virtualbox: No issue with valgrind 3.15.0 and 3.17.0, g++ 4.8.5, GLIBC 2.17 CentOS 8 inside Virtualbox: Issue reproducible with valgrind 3.22, g++ 8.5.0, GLIBC 2.28 and same with valgrind 3.15 built from source See the -q outputs of valgrind below. So I conclude from this that it is an issue through all versions of valgrind, but the issue happens only on VMs and might depend on the GLIBC version. Any idea? Long shot, but between the versions above there were some changes to __memchr_sse2 such as https://github.com/bminor/glibc/commit/2f5d20ac99b9434a634629282cbb46e2a8d56a1 and https://github.com/bminor/glibc/commit/3edda6a0f013736ca9554a95e553739a41dbd4b7 AMD Ryzen 5 5500U with Radeon Graphics, Linux fedora 6.10.6-200.fc40.x86_64 #1 SMP PREEMPT_DYNAMIC Mon Aug 19 14:09:30 UTC 2024 x86_64 GNU/Linux ==5006== Massif, a heap profiler ==5006== Copyright (C) 2003-2024, and GNU GPL'd, by Nicholas Nethercote et al. ==5006== Using Valgrind-3.23.0-c54d316124-20240426 and LibVEX; rerun with -h for copyright info ==5006== Command: ./a.out ==5006== --5006-- Valgrind options: --5006-- -v --5006-- --tool=massif --5006-- Contents of /proc/version: --5006-- Linux version 6.10.6-200.fc40.x86_64 (mockbuild@f1069ead281040288cd8d3761ad1265a) (gcc (GCC) 14.2.1 20240801 (Red Hat 14.2.1-1), GNU ld version 2.41-37.fc40) #1 SMP PREEMPT_DYNAMIC Mon Aug 19 14:09:30 UTC 2024 --5006-- --5006-- Arch and hwcaps: AMD64, LittleEndian, amd64-cx16-lzcnt-rdtscp-sse3-ssse3-avx-avx2-bmi-f16c-rdrand-rdseed-fma CentOS 7 VM, i7-9700, Linux localhost.localdomain 3.10.0-1160.el7.x86_64 #1 SMP Mon Oct 19 16:18:59 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux ==4171== Massif, a heap profiler ==4171== Copyright (C) 2003-2017, and GNU GPL'd, by Nicholas Nethercote ==4171== Using Valgrind-3.15.0-608cb11914-20190413 and LibVEX; rerun with -h for copyright info ==4171== Command: ./a.out ==4171== --4171-- Valgrind options: --4171-- -v --4171-- --tool=massif --4171-- Contents of /proc/version: --4171-- Linux version 3.10.0-1160.el7.x86_64 (mockbuild@kbuilder.bsys.centos.org) (gcc version 4.8.5 20150623 (Red Hat 4.8.5-44) (GCC) ) #1 SMP Mon Oct 19 16:18:59 UTC 2020 --4171-- --4171-- Arch and hwcaps: AMD64, LittleEndian, amd64-cx16-lzcnt-rdtscp-sse3-ssse3-avx-avx2-rdrand --4171-- Page sizes: currently 4096, max supported 4096 --4171-- Valgrind library directory: /usr/libexec/valgrind --4171-- Massif: alloc-fns: --4171-- Massif: malloc --4171-- Massif: __builtin_new --4171-- Massif: operator new(unsigned) --4171-- Massif: operator new(unsigned long) --4171-- Massif: __builtin_vec_new --4171-- Massif: operator new[](unsigned) --4171-- Massif: operator new[](unsigned long) --4171-- Massif: calloc --4171-- Massif: realloc --4171-- Massif: memalign --4171-- Massif: posix_memalign --4171-- Massif: valloc --4171-- Massif: operator new(unsigned, std::nothrow_t const&) --4171-- Massif: operator new[](unsigned, std::nothrow_t const&) --4171-- Massif: operator new(unsigned long, std::nothrow_t const&) --4171-- Massif: operator new[](unsigned long, std::nothrow_t const&) --4171-- Massif: ignore-fns: --4171-- Massif: <empty> --4171-- Reading syms from /home/svf/a.out --4171-- Reading syms from /usr/lib64/ld-2.17.so --4171-- Reading syms from /usr/libexec/valgrind/massif-amd64-linux --4171-- object doesn't have a symbol table --4171-- object doesn't have a dynamic symbol table --4171-- Scheduler: using generic scheduler lock implementation. ==4171== embedded gdbserver: reading from /tmp/vgdb-pipe-from-vgdb-to-4171-by-svf-on-localhost.localdomain ==4171== embedded gdbserver: writing to /tmp/vgdb-pipe-to-vgdb-from-4171-by-svf-on-localhost.localdomain ==4171== embedded gdbserver: shared mem /tmp/vgdb-pipe-shared-mem-vgdb-4171-by-svf-on-localhost.localdomain ==4171== ==4171== TO CONTROL THIS PROCESS USING vgdb (which you probably ==4171== don't want to do, unless you know exactly what you're doing, ==4171== or are doing some strange experiment): ==4171== /usr/libexec/valgrind/../../bin/vgdb --pid=4171 ...command... ==4171== ==4171== TO DEBUG THIS PROCESS USING GDB: start GDB like this ==4171== /path/to/gdb ./a.out ==4171== and then give GDB the following command ==4171== target remote | /usr/libexec/valgrind/../../bin/vgdb --pid=4171 ==4171== --pid is optional if only one valgrind process is running ==4171== --4171-- Reading syms from /usr/libexec/valgrind/vgpreload_core-amd64-linux.so --4171-- Reading syms from /usr/libexec/valgrind/vgpreload_massif-amd64-linux.so --4171-- Reading syms from /usr/lib64/libstdc++.so.6.0.19 --4171-- object doesn't have a symbol table --4171-- Reading syms from /usr/lib64/libm-2.17.so --4171-- Reading syms from /usr/lib64/libgcc_s-4.8.5-20150702.so.1 --4171-- object doesn't have a symbol table --4171-- Reading syms from /usr/lib64/libc-2.17.so 0 --4171-- REDIR: 0x56d2ad0 (libc.so.6:free) redirected to 0x4c291a6 (free) ==4171== CentOS 8 VM, valgrind 3.22, g++ 8.5.0 Linux localhost.localdomain 4.18.0-539.el8.x86_64 #1 SMP Mon Feb 5 18:34:56 UTC 2024 x86_64 x86_64 x86_64 GNU/Linux ==9575== Massif, a heap profiler ==9575== Copyright (C) 2003-2017, and GNU GPL'd, by Nicholas Nethercote ==9575== Using Valgrind-3.22.0-bd4db67b1d-20231031 and LibVEX; rerun with -h for copyright info ==9575== Command: ./a.out ==9575== --9575-- Valgrind options: --9575-- -v --9575-- --tool=massif --9575-- Contents of /proc/version: --9575-- Linux version 4.18.0-539.el8.x86_64 (mockbuild@x86-05.stream.rdu2.redhat.com) (gcc version 8.5.0 20210514 (Red Hat 8.5.0-21) (GCC)) #1 SMP Mon Feb 5 18:34:56 UTC 2024 --9575-- --9575-- Arch and hwcaps: AMD64, LittleEndian, amd64-cx16-lzcnt-rdtscp-sse3-ssse3-avx-avx2-rdrand-rdseed --9575-- Page sizes: currently 4096, max supported 4096 --9575-- Valgrind library directory: /usr/libexec/valgrind --9575-- Massif: alloc-fns: --9575-- Massif: malloc --9575-- Massif: __builtin_new --9575-- Massif: operator new(unsigned) --9575-- Massif: operator new(unsigned long) --9575-- Massif: __builtin_vec_new --9575-- Massif: operator new[](unsigned) --9575-- Massif: operator new[](unsigned long) --9575-- Massif: calloc --9575-- Massif: realloc --9575-- Massif: memalign --9575-- Massif: posix_memalign --9575-- Massif: valloc --9575-- Massif: operator new(unsigned, std::nothrow_t const&) --9575-- Massif: operator new[](unsigned, std::nothrow_t const&) --9575-- Massif: operator new(unsigned long, std::nothrow_t const&) --9575-- Massif: operator new[](unsigned long, std::nothrow_t const&) --9575-- Massif: ignore-fns: --9575-- Massif: <empty> --9575-- Reading syms from /home/svf/a.out --9575-- Reading syms from /usr/lib64/ld-2.28.so --9575-- Reading syms from /usr/libexec/valgrind/massif-amd64-linux --9575-- object doesn't have a dynamic symbol table --9575-- Scheduler: using generic scheduler lock implementation. ==9575== embedded gdbserver: reading from /tmp/vgdb-pipe-from-vgdb-to-9575-by-svf-on-localhost.localdomain ==9575== embedded gdbserver: writing to /tmp/vgdb-pipe-to-vgdb-from-9575-by-svf-on-localhost.localdomain ==9575== embedded gdbserver: shared mem /tmp/vgdb-pipe-shared-mem-vgdb-9575-by-svf-on-localhost.localdomain ==9575== ==9575== TO CONTROL THIS PROCESS USING vgdb (which you probably ==9575== don't want to do, unless you know exactly what you're doing, ==9575== or are doing some strange experiment): ==9575== /usr/libexec/valgrind/../../bin/vgdb --pid=9575 ...command... ==9575== ==9575== TO DEBUG THIS PROCESS USING GDB: start GDB like this ==9575== /path/to/gdb ./a.out ==9575== and then give GDB the following command ==9575== target remote | /usr/libexec/valgrind/../../bin/vgdb --pid=9575 ==9575== --pid is optional if only one valgrind process is running ==9575== --9575-- Reading syms from /usr/libexec/valgrind/vgpreload_core-amd64-linux.so --9575-- Reading syms from /usr/libexec/valgrind/vgpreload_massif-amd64-linux.so --9575-- Reading syms from /usr/lib64/libstdc++.so.6.0.25 --9575-- Reading syms from /usr/lib64/libm-2.28.so --9575-- Reading syms from /usr/lib64/libgcc_s-8-20210514.so.1 --9575-- Reading syms from /usr/lib64/libc-2.28.so ==9575== Downloading debug info for /usr/lib64/libc-2.28.so... ==9575== Server query failed: No such file or directory ==9575== WARNING: new redirection conflicts with existing -- ignoring it --9575-- old: 0x0580df50 (memalign ) R-> (1011.0) 0x04c3edae memalign --9575-- new: 0x0580df50 (memalign ) R-> (1017.0) 0x04c3f537 aligned_alloc ==9575== WARNING: new redirection conflicts with existing -- ignoring it --9575-- old: 0x0580df50 (memalign ) R-> (1011.0) 0x04c3edae memalign --9575-- new: 0x0580df50 (memalign ) R-> (1017.0) 0x04c3f3cd aligned_alloc ==9575== WARNING: new redirection conflicts with existing -- ignoring it --9575-- old: 0x0580df50 (memalign ) R-> (1011.0) 0x04c3edae memalign --9575-- new: 0x0580df50 (memalign ) R-> (1017.0) 0x04c3f537 aligned_alloc ==9575== WARNING: new redirection conflicts with existing -- ignoring it --9575-- old: 0x0580df50 (memalign ) R-> (1011.0) 0x04c3edae memalign --9575-- new: 0x0580df50 (memalign ) R-> (1017.0) 0x04c3f3cd aligned_alloc ==9575== WARNING: new redirection conflicts with existing -- ignoring it --9575-- old: 0x0580df50 (memalign ) R-> (1011.0) 0x04c3edae memalign --9575-- new: 0x0580df50 (memalign ) R-> (1017.0) 0x04c3f537 aligned_alloc ==9575== WARNING: new redirection conflicts with existing -- ignoring it --9575-- old: 0x0580df50 (memalign ) R-> (1011.0) 0x04c3edae memalign --9575-- new: 0x0580df50 (memalign ) R-> (1017.0) 0x04c3f3cd aligned_alloc --9575-- REDIR: 0x580d1e0 (libc.so.6:malloc) redirected to 0x4c3711f (malloc) ==9575== Downloading debug info for /usr/lib64/libstdc++.so.6.0.25... ==9575== Server query failed: No such file or directory --9575-- Warning: cross-CU LIMITATION: some inlined fn names --9575-- might be shown as UnknownInlinedFun ==9575== Downloading debug info for /home/svf/a.out... ==9575== Server query failed: No such file or directory 0x1ffefff43e --9575-- REDIR: 0x580d870 (libc.so.6:free) redirected to 0x4c3a469 (free) ==9575==