It is not a performance issue, after printing the logs, I can see the below errors:
-valgrind --tool=memcheck --trace-children=yes ./valgrind-test 2>/dev/null
+valgrind -v --tool=memcheck --trace-children=yes ./valgrind-test
logs:
+ valgrind -v --tool=memcheck --trace-children=yes ./valgrind-test
==2050== Memcheck, a memory error detector
==2050== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==2050== Using Valgrind-3.18.1-42b08ed5bd-20211015 and LibVEX; rerun with -h for copyright info
==2050== Command: ./valgrind-test
==2050==
--2050-- Valgrind options:
--2050-- -v
--2050-- --tool=memcheck
--2050-- --trace-children=yes
--2050-- Contents of /proc/version:
--2050-- Linux version 5.14.21-150400.24.28-default (geeko@buildhost) (gcc (SUSE Linux) 7.5.0, GNU ld (GNU Binutils; SUSE Linux Enterprise 15) 2.37.20211103-150100.7.37) #1 SMP PREEMPT_DYNAMIC Mon Oct 10 15:21:12 UTC 2022 (f82da2c)
--2050--
--2050-- Arch and hwcaps: ARM64, LittleEndian, v8-atomics
--2050-- Page sizes: currently 4096, max supported 65536
--2050-- Valgrind library directory: /usr/lib/valgrind
--2050-- Reading syms from /var/tmp/valgrind-test
--2050-- Reading syms from /lib64/ld-2.31.so
--2050-- Reading syms from /usr/lib/valgrind/memcheck-arm64-linux
--2050-- object doesn't have a symbol table
--2050-- object doesn't have a dynamic symbol table
--2050-- Scheduler: using generic scheduler lock implementation.
--2050-- Reading suppressions file: /usr/lib/valgrind/default.supp
==2050== embedded gdbserver: reading from /tmp/vgdb-pipe-from-vgdb-to-2050-by-root-on-susetest
==2050== embedded gdbserver: writing to /tmp/vgdb-pipe-to-vgdb-from-2050-by-root-on-susetest
==2050== embedded gdbserver: shared mem /tmp/vgdb-pipe-shared-mem-vgdb-2050-by-root-on-susetest
==2050==
==2050== TO CONTROL THIS PROCESS USING vgdb (which you probably
==2050== don't want to do, unless you know exactly what you're doing,
==2050== or are doing some strange experiment):
==2050== /usr/lib/valgrind/../../bin/vgdb --pid=2050 ...command...
==2050==
==2050== TO DEBUG THIS PROCESS USING GDB: start GDB like this
==2050== /path/to/gdb ./valgrind-test
==2050== and then give GDB the following command
==2050== target remote | /usr/lib/valgrind/../../bin/vgdb --pid=2050
==2050== --pid is optional if only one valgrind process is running
==2050==
VEX: Mismatch detected between RDMA and atomics features.
Found: v8-atomics
Cannot continue. Good-bye
vex storage: T total 0 bytes allocated
vex storage: P total 0 bytes allocated
valgrind: the 'impossible' happened:
LibVEX called failure_exit().
However, I can't see the issue on my local setup, it might have something to do with the hardware configration.
My setup:
# lscpu|grep Flags
Flags: fp asimd evtstrm aes pmull sha1 sha2 crc32 cpuid
openQA workers:
# lscpu; echo 5GZT6-$?-
Architecture: aarch64
CPU op-mode(s): 64-bit
Byte Order: Little Endian
CPU(s): 4
On-line CPU(s) list: 0-3
Vendor ID: Cavium
Model name: ThunderX 88XX
Model: 1
Thread(s) per core: 1
Core(s) per socket: 4
Socket(s): 1
Stepping: 0x1
BogoMIPS: 200.00
Flags: fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics cpuid
NUMA:
NUMA node(s): 1
NUMA node0 CPU(s): 0-3
Let me try to file a bug