https://bugs.kde.org/show_bug.cgi?id=492549
--- Comment #11 from martin.lu...@ohb.de ---
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==
--
You are receiving this mail because:
You are watching all bug changes.
