| Summary: | unhandled instruction bytes: 0x62 0xF1 0x7F 0x48 0x7F 0x44 0x24 0x1 0x83 0xE7 | ||
|---|---|---|---|
| Product: | [Developer tools] valgrind | Reporter: | tusooa <tusooa> |
| Component: | vex | Assignee: | Julian Seward <jseward> |
| Status: | RESOLVED DUPLICATE | ||
| Severity: | normal | CC: | me, tom |
| Priority: | NOR | ||
| Version: | 3.20.0 | ||
| Target Milestone: | --- | ||
| Platform: | Other | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
| Attachments: | cpuinfo | ||
|
Description
tusooa
2023-05-17 01:31:12 UTC
==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? |