[valgrind] [Bug 469878] unhandled instruction bytes: 0x62 0xF1 0x7F 0x48 0x7F 0x44 0x24 0x1 0x83 0xE7
https://bugs.kde.org/show_bug.cgi?id=469878 Martin Kjær Jørgensen changed: What|Removed |Added CC||m...@lagy.org --- Comment #3 from Martin Kjær Jørgensen --- (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.n=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? -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 469878] unhandled instruction bytes: 0x62 0xF1 0x7F 0x48 0x7F 0x44 0x24 0x1 0x83 0xE7
https://bugs.kde.org/show_bug.cgi?id=469878 Tom Hughes changed: What|Removed |Added CC||t...@compton.nu Resolution|--- |DUPLICATE Status|REPORTED|RESOLVED --- Comment #2 from Tom Hughes --- That's an AVX-512 instruction. *** This bug has been marked as a duplicate of bug 383010 *** -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 469878] unhandled instruction bytes: 0x62 0xF1 0x7F 0x48 0x7F 0x44 0x24 0x1 0x83 0xE7
https://bugs.kde.org/show_bug.cgi?id=469878 --- Comment #1 from tusooa --- ==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.n=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.
[valgrind] [Bug 469878] unhandled instruction bytes: 0x62 0xF1 0x7F 0x48 0x7F 0x44 0x24 0x1 0x83 0xE7
https://bugs.kde.org/show_bug.cgi?id=469878 tusooa changed: What|Removed |Added Component|general |vex -- You are receiving this mail because: You are watching all bug changes.
