SUMMARY vex amd64->IR: unhandled instruction bytes: 0x62 0xF1 0x7F 0x48 0x7F 0x84 0x24 0x30 0x0 0x0 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 ==722282== valgrind: Unrecognised instruction at address 0x402a0fd. ==722282== at 0x402A0FD: _dl_start (rtld.c:566) ==722282== by 0x40291C7: ??? (in /usr/lib/ld-linux-x86-64.so.2) c STEPS TO REPRODUCE 1. ❯ cat helloWorld.c #include <stdio.h> int main(int argc,char**argv){ puts("hello world"); return 0; } 2. ❯ gcc -g helloWorld.c 3. ❯ ./a.out hello world 4. ❯ valgrind ./a.out OBSERVED RESULT ❯ valgrind ./a.out ==722282== Memcheck, a memory error detector ==722282== Copyright (C) 2002-2024, and GNU GPL'd, by Julian Seward et al. ==722282== Using Valgrind-3.25.1 and LibVEX; rerun with -h for copyright info ==722282== Command: ./a.out ==722282== vex amd64->IR: unhandled instruction bytes: 0x62 0xF1 0x7F 0x48 0x7F 0x84 0x24 0x30 0x0 0x0 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 ==722282== valgrind: Unrecognised instruction at address 0x402a0fd. ==722282== at 0x402A0FD: _dl_start (rtld.c:566) ==722282== by 0x40291C7: ??? (in /usr/lib/ld-linux-x86-64.so.2) ==722282== Your program just tried to execute an instruction that Valgrind ==722282== did not recognise. There are two possible reasons for this. ==722282== 1. Your program has a bug and erroneously jumped to a non-code ==722282== location. If you are running Memcheck and you just saw a ==722282== warning about a bad jump, it's probably your program's fault. ==722282== 2. The instruction is legitimate but Valgrind doesn't handle it, ==722282== i.e. it's Valgrind's fault. If you think this is the case or ==722282== you are not sure, please let us know and we'll try to fix it. ==722282== Either way, Valgrind will now raise a SIGILL signal which will ==722282== probably kill your program. ==722282== ==722282== Process terminating with default action of signal 4 (SIGILL): dumping core ==722282== Illegal opcode at address 0x402A0FD ==722282== at 0x402A0FD: _dl_start (rtld.c:566) ==722282== by 0x40291C7: ??? (in /usr/lib/ld-linux-x86-64.so.2) ==722282== ==722282== HEAP SUMMARY: ==722282== in use at exit: 0 bytes in 0 blocks ==722282== total heap usage: 0 allocs, 0 frees, 0 bytes allocated ==722282== ==722282== All heap blocks were freed -- no leaks are possible ==722282== ==722282== For lists of detected and suppressed errors, rerun with: -s ==722282== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0) fish: Job 1, 'valgrind ./a.out' terminated by signal SIGILL (Illegal instruction) EXPECTED RESULT it should work instead SOFTWARE/OS VERSIONS Windows: macOS: (available in the Info Center app, or by running `kinfo` in a terminal window) Linux/KDE Plasma: KDE Plasma Version: KDE Frameworks Version: Qt Version: ❯ kinfo WARNING: radv is not a conformant Vulkan implementation, testing use only. Operating System: CachyOS Linux KDE Plasma Version: 6.5.3 KDE Frameworks Version: 6.20.0 Qt Version: 6.10.1 Kernel Version: 6.18.0-3-cachyos (64-bit) Graphics Platform: Wayland Processors: 32 × AMD Ryzen 9 7950X3D 16-Core Processor Memory: 64 GiB of RAM (62.4 GiB usable) Graphics Processor: AMD Radeon RX 9070 XT ADDITIONAL INFORMATION
If you want to use Valgrind you will need to try another OS. Your dynamic loader is using instructions that Valgrind does not support. *** This bug has been marked as a duplicate of bug 383010 ***
hmm, okay. I have followed a tutorial to use Distrobox to run ubuntu VM and it seems that after rebuilding and testing valgrind again inside the distrobox ubuntu shell, that it is working now. So I think I can do this then.