https://bugs.kde.org/show_bug.cgi?id=469878
--- Comment #1 from tusooa <tus...@kazv.moe> --- ==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 -- You are receiving this mail because: You are watching all bug changes.
