Created attachment 159023 [details] cpuinfo SUMMARY *** NOTE: If you are reporting a crash, please try to attach a backtrace with debug symbols. See https://community.kde.org/Guidelines_and_HOWTOs/Debugging/How_to_create_useful_crash_reports *** STEPS TO REPRODUCE 1. valgrind ls 2. 3. OBSERVED RESULT ==8232== Memcheck, a memory error detector ==8232== Copyright (C) 2002-2022, and GNU GPL'd, by Julian Seward et al. ==8232== Using Valgrind-3.20.0 and LibVEX; rerun with -h for copyright info ==8232== Command: ls ==8232== vex amd64->IR: unhandled instruction bytes: 0x62 0xF1 0x7F 0x48 0x7F 0x44 0x24 0x1 0x83 0xE7 vex amd64->IR: REX=0 REX.W=0 REX.R=0 REX.X=0 REX.B=0 vex amd64->IR: VEX=0 VEX.L=0 VEX.nVVVV=0x0 ESC=NONE vex amd64->IR: PFX.66=0 PFX.F2=0 PFX.F3=0 ==8232== valgrind: Unrecognised instruction at address 0x401c126. ==8232== at 0x401C126: _dl_start (rtld.c:566) ==8232== by 0x401B1D7: ??? (in /lib64/ld-linux-x86-64.so.2) ==8232== Your program just tried to execute an instruction that Valgrind ==8232== did not recognise. There are two possible reasons for this. ==8232== 1. Your program has a bug and erroneously jumped to a non-code ==8232== location. If you are running Memcheck and you just saw a ==8232== warning about a bad jump, it's probably your program's fault. ==8232== 2. The instruction is legitimate but Valgrind doesn't handle it, ==8232== i.e. it's Valgrind's fault. If you think this is the case or ==8232== you are not sure, please let us know and we'll try to fix it. ==8232== Either way, Valgrind will now raise a SIGILL signal which will ==8232== probably kill your program. ==8232== ==8232== Process terminating with default action of signal 4 (SIGILL): dumping core ==8232== Illegal opcode at address 0x401C126 ==8232== at 0x401C126: _dl_start (rtld.c:566) ==8232== by 0x401B1D7: ??? (in /lib64/ld-linux-x86-64.so.2) ==8232== ==8232== HEAP SUMMARY: ==8232== in use at exit: 0 bytes in 0 blocks ==8232== total heap usage: 0 allocs, 0 frees, 0 bytes allocated ==8232== ==8232== All heap blocks were freed -- no leaks are possible ==8232== ==8232== For lists of detected and suppressed errors, rerun with: -s ==8232== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0) EXPECTED RESULT it should work SOFTWARE/OS VERSIONS Windows: macOS: Linux/KDE Plasma: 6.1.27 (available in About System) KDE Plasma Version: KDE Frameworks Version: Qt Version: ADDITIONAL INFORMATION /proc/cpuinfo is attached. This is a Gentoo compiled with */* CPU_FLAGS_X86: aes avx avx2 avx512f avx512dq avx512cd avx512bw avx512vl avx512vbmi f16c fma3 mmx mmxext pclmul popcnt rdrand sha sse sse2 sse3 sse4_1 sse4_2 sse4a ssse3 and glibc is compiled with CFLAGS="${CFLAGS} -fno-builtin-strlen -ggdb3" CXXFLAGS="${CXXFLAGS} -ggdb3" FEATURES="${FEATURES} splitdebug compressdebug -nostrip installsources"
==9898== Memcheck, a memory error detector ==9898== Copyright (C) 2002-2022, and GNU GPL'd, by Julian Seward et al. ==9898== Using Valgrind-3.20.0-5147d671e4-20221024 and LibVEX; rerun with -h for copyright info ==9898== Command: ls ==9898== --9898-- Valgrind options: --9898-- -v --9898-- Contents of /proc/version: --9898-- Linux version 6.1.27-gentoo-r1-x86_64 (REDACTED@REDACTED) (x86_64-pc-linux-gnu-gcc (Gentoo 12.2.1_p20230428-r1 p2) 12.2.1 20230428, GNU ld (Gentoo 2.39 p6) 2.39.0) #1 SMP PREEMPT_DYNAMIC Wed May 10 18:30:00 EDT 2023 --9898-- --9898-- Arch and hwcaps: AMD64, LittleEndian, amd64-cx16-lzcnt-rdtscp-sse3-ssse3-avx-avx2-bmi-f16c-rdrand-rdseed --9898-- Page sizes: currently 4096, max supported 4096 --9898-- Valgrind library directory: /usr/libexec/valgrind --9898-- Reading syms from /bin/ls --9898-- object doesn't have a symbol table --9898-- Reading syms from /lib64/ld-linux-x86-64.so.2 --9898-- Considering /usr/lib/debug/lib64/ld-linux-x86-64.so.2.debug .. --9898-- .. CRC is valid --9898-- Reading syms from /usr/libexec/valgrind/memcheck-amd64-linux --9898-- object doesn't have a symbol table --9898-- object doesn't have a dynamic symbol table --9898-- Scheduler: using generic scheduler lock implementation. --9898-- Reading suppressions file: /usr/libexec/valgrind/default.supp ==9898== embedded gdbserver: reading from /tmp/vgdb-pipe-from-vgdb-to-9898-by-user-on-??? ==9898== embedded gdbserver: writing to /tmp/vgdb-pipe-to-vgdb-from-9898-by-user-on-??? ==9898== embedded gdbserver: shared mem /tmp/vgdb-pipe-shared-mem-vgdb-9898-by-user-on-??? ==9898== ==9898== TO CONTROL THIS PROCESS USING vgdb (which you probably ==9898== don't want to do, unless you know exactly what you're doing, ==9898== or are doing some strange experiment): ==9898== /usr/libexec/valgrind/../../bin/vgdb --pid=9898 ...command... ==9898== ==9898== TO DEBUG THIS PROCESS USING GDB: start GDB like this ==9898== /path/to/gdb ls ==9898== and then give GDB the following command ==9898== target remote | /usr/libexec/valgrind/../../bin/vgdb --pid=9898 ==9898== --pid is optional if only one valgrind process is running ==9898== vex amd64->IR: unhandled instruction bytes: 0x62 0xF1 0x7F 0x48 0x7F 0x44 0x24 0x1 0x83 0xE7 vex amd64->IR: REX=0 REX.W=0 REX.R=0 REX.X=0 REX.B=0 vex amd64->IR: VEX=0 VEX.L=0 VEX.nVVVV=0x0 ESC=NONE vex amd64->IR: PFX.66=0 PFX.F2=0 PFX.F3=0 ==9898== valgrind: Unrecognised instruction at address 0x401c126. ==9898== at 0x401C126: _dl_start (rtld.c:566) ==9898== by 0x401B1D7: ??? (in /lib64/ld-linux-x86-64.so.2) ==9898== Your program just tried to execute an instruction that Valgrind ==9898== did not recognise. There are two possible reasons for this. ==9898== 1. Your program has a bug and erroneously jumped to a non-code ==9898== location. If you are running Memcheck and you just saw a ==9898== warning about a bad jump, it's probably your program's fault. ==9898== 2. The instruction is legitimate but Valgrind doesn't handle it, ==9898== i.e. it's Valgrind's fault. If you think this is the case or ==9898== you are not sure, please let us know and we'll try to fix it. ==9898== Either way, Valgrind will now raise a SIGILL signal which will ==9898== probably kill your program. ==9898== ==9898== Process terminating with default action of signal 4 (SIGILL): dumping core ==9898== Illegal opcode at address 0x401C126 ==9898== at 0x401C126: _dl_start (rtld.c:566) ==9898== by 0x401B1D7: ??? (in /lib64/ld-linux-x86-64.so.2) ==9898== ==9898== HEAP SUMMARY: ==9898== in use at exit: 0 bytes in 0 blocks ==9898== total heap usage: 0 allocs, 0 frees, 0 bytes allocated ==9898== ==9898== All heap blocks were freed -- no leaks are possible ==9898== ==9898== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0) zsh: illegal hardware instruction valgrind -v ls
That's an AVX-512 instruction. *** This bug has been marked as a duplicate of bug 383010 ***
(In reply to tusooa from comment #1) > ==9898== Memcheck, a memory error detector > ==9898== Copyright (C) 2002-2022, and GNU GPL'd, by Julian Seward et al. > ==9898== Using Valgrind-3.20.0-5147d671e4-20221024 and LibVEX; rerun with -h > for copyright info > ==9898== Command: ls > ==9898== > --9898-- Valgrind options: > --9898-- -v > --9898-- Contents of /proc/version: > --9898-- Linux version 6.1.27-gentoo-r1-x86_64 (REDACTED@REDACTED) > (x86_64-pc-linux-gnu-gcc (Gentoo 12.2.1_p20230428-r1 p2) 12.2.1 20230428, > GNU ld (Gentoo 2.39 p6) 2.39.0) #1 SMP PREEMPT_DYNAMIC Wed May 10 18:30:00 > EDT 2023 > --9898-- > --9898-- Arch and hwcaps: AMD64, LittleEndian, > amd64-cx16-lzcnt-rdtscp-sse3-ssse3-avx-avx2-bmi-f16c-rdrand-rdseed > --9898-- Page sizes: currently 4096, max supported 4096 > --9898-- Valgrind library directory: /usr/libexec/valgrind > --9898-- Reading syms from /bin/ls > --9898-- object doesn't have a symbol table > --9898-- Reading syms from /lib64/ld-linux-x86-64.so.2 > --9898-- Considering /usr/lib/debug/lib64/ld-linux-x86-64.so.2.debug .. > --9898-- .. CRC is valid > --9898-- Reading syms from /usr/libexec/valgrind/memcheck-amd64-linux > --9898-- object doesn't have a symbol table > --9898-- object doesn't have a dynamic symbol table > --9898-- Scheduler: using generic scheduler lock implementation. > --9898-- Reading suppressions file: /usr/libexec/valgrind/default.supp > ==9898== embedded gdbserver: reading from > /tmp/vgdb-pipe-from-vgdb-to-9898-by-user-on-??? > ==9898== embedded gdbserver: writing to > /tmp/vgdb-pipe-to-vgdb-from-9898-by-user-on-??? > ==9898== embedded gdbserver: shared mem > /tmp/vgdb-pipe-shared-mem-vgdb-9898-by-user-on-??? > ==9898== > ==9898== TO CONTROL THIS PROCESS USING vgdb (which you probably > ==9898== don't want to do, unless you know exactly what you're doing, > ==9898== or are doing some strange experiment): > ==9898== /usr/libexec/valgrind/../../bin/vgdb --pid=9898 ...command... > ==9898== > ==9898== TO DEBUG THIS PROCESS USING GDB: start GDB like this > ==9898== /path/to/gdb ls > ==9898== and then give GDB the following command > ==9898== target remote | /usr/libexec/valgrind/../../bin/vgdb --pid=9898 > ==9898== --pid is optional if only one valgrind process is running > ==9898== > vex amd64->IR: unhandled instruction bytes: 0x62 0xF1 0x7F 0x48 0x7F 0x44 > 0x24 0x1 0x83 0xE7 > vex amd64->IR: REX=0 REX.W=0 REX.R=0 REX.X=0 REX.B=0 > vex amd64->IR: VEX=0 VEX.L=0 VEX.nVVVV=0x0 ESC=NONE > vex amd64->IR: PFX.66=0 PFX.F2=0 PFX.F3=0 > ==9898== valgrind: Unrecognised instruction at address 0x401c126. > ==9898== at 0x401C126: _dl_start (rtld.c:566) > ==9898== by 0x401B1D7: ??? (in /lib64/ld-linux-x86-64.so.2) > ==9898== Your program just tried to execute an instruction that Valgrind > ==9898== did not recognise. There are two possible reasons for this. > ==9898== 1. Your program has a bug and erroneously jumped to a non-code > ==9898== location. If you are running Memcheck and you just saw a > ==9898== warning about a bad jump, it's probably your program's fault. > ==9898== 2. The instruction is legitimate but Valgrind doesn't handle it, > ==9898== i.e. it's Valgrind's fault. If you think this is the case or > ==9898== you are not sure, please let us know and we'll try to fix it. > ==9898== Either way, Valgrind will now raise a SIGILL signal which will > ==9898== probably kill your program. > ==9898== > ==9898== Process terminating with default action of signal 4 (SIGILL): > dumping core > ==9898== Illegal opcode at address 0x401C126 > ==9898== at 0x401C126: _dl_start (rtld.c:566) > ==9898== by 0x401B1D7: ??? (in /lib64/ld-linux-x86-64.so.2) > ==9898== > ==9898== HEAP SUMMARY: > ==9898== in use at exit: 0 bytes in 0 blocks > ==9898== total heap usage: 0 allocs, 0 frees, 0 bytes allocated > ==9898== > ==9898== All heap blocks were freed -- no leaks are possible > ==9898== > ==9898== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0) > zsh: illegal hardware instruction valgrind -v ls Did you work around your AXV512 issue?