| View previous topic :: View next topic |
| Author |
Message |
ONEEYEMAN
Advocate
Joined: 01 Mar 2005
Posts: 3674
|
 Posted: Mon Dec 30, 2024 5:49 am Post subject: Valgrind run failure |
 |
|
Hi, ALL,
I just tried to run my program with the following command:
| Code: |
igor@WaylandGnome ~/dbhandler/Debug/dbhandler $ valgrind --leak-check=full \
--show-leak-kinds=all \
--track-origins=yes \
--verbose \
--log-file=valgrind-out.txt \
./dbhandler
Illegal instruction
|
(the command comes from https://stackoverflow.com/questions/5134891/how-do-i-use-valgrind-to-find-memory-leaks)
Looking at the log file produced I see the following:
| Code: |
igor@WaylandGnome ~/dbhandler/Debug/dbhandler $ cat valgrind-out.txt
==9030== Memcheck, a memory error detector
==9030== Copyright (C) 2002-2022, and GNU GPL'd, by Julian Seward et al.
==9030== Using Valgrind-3.21.0-d97fed7c3e-20230428 and LibVEX; rerun with -h for copyright info
==9030== Command: ./dbhandler
==9030== Parent PID: 4692
==9030==
--9030--
--9030-- Valgrind options:
--9030-- --leak-check=full
--9030-- --show-leak-kinds=all
--9030-- --track-origins=yes
--9030-- --verbose
--9030-- --log-file=valgrind-out.txt
--9030-- Contents of /proc/version:
--9030-- Linux version 6.6.21-gentoo (root@WaylandGnome) (gcc (Gentoo 13.2.1_p20240210 p14) 13.2.1 20240210, GNU ld (Gentoo 2.41 p5) 2.41.0) #6 SMP Sat Aug 3 02:21:28 CDT 2024
--9030--
--9030-- Arch and hwcaps: AMD64, LittleEndian, amd64-cx16-lzcnt-rdtscp-sse3-ssse3-avx-avx2-bmi-f16c
--9030-- Page sizes: currently 4096, max supported 4096
--9030-- Valgrind library directory: /usr/libexec/valgrind
--9030-- Reading syms from /home/igor/dbhandler/Debug/dbhandler/dbhandler
--9030-- Reading syms from /lib64/ld-linux-x86-64.so.2
--9030-- Reading syms from /usr/libexec/valgrind/memcheck-amd64-linux
--9030-- Considering /usr/lib/debug/usr/libexec/valgrind/memcheck-amd64-linux.debug ..
--9030-- .. CRC is valid
--9030-- object doesn't have a dynamic symbol table
--9030-- Scheduler: using generic scheduler lock implementation.
--9030-- Reading suppressions file: /usr/libexec/valgrind/default.supp
==9030== embedded gdbserver: reading from /tmp/vgdb-pipe-from-vgdb-to-9030-by-igor-on-???
==9030== embedded gdbserver: writing to /tmp/vgdb-pipe-to-vgdb-from-9030-by-igor-on-???
==9030== embedded gdbserver: shared mem /tmp/vgdb-pipe-shared-mem-vgdb-9030-by-igor-on-???
==9030==
==9030== TO CONTROL THIS PROCESS USING vgdb (which you probably
==9030== don't want to do, unless you know exactly what you're doing,
==9030== or are doing some strange experiment):
==9030== /usr/libexec/valgrind/../../bin/vgdb --pid=9030 ...command...
==9030==
==9030== TO DEBUG THIS PROCESS USING GDB: start GDB like this
==9030== /path/to/gdb ./dbhandler
==9030== and then give GDB the following command
==9030== target remote | /usr/libexec/valgrind/../../bin/vgdb --pid=9030
==9030== --pid is optional if only one valgrind process is running
==9030==
vex amd64->IR: unhandled instruction bytes: 0x8F 0xEA 0x78 0x10 0xD0 0x8 0x4 0x0 0x0 0x89
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
==9030== valgrind: Unrecognised instruction at address 0x40149d7.
==9030== at 0x40149D7: get_common_indices.constprop.0 (in /lib64/ld-linux-x86-64.so.2)
==9030== by 0x401604E: init_cpu_features.constprop.0 (in /lib64/ld-linux-x86-64.so.2)
==9030== by 0x4016360: _dl_x86_init_cpu_features (in /lib64/ld-linux-x86-64.so.2)
==9030== by 0x401974B: _dl_sysdep_start (in /lib64/ld-linux-x86-64.so.2)
==9030== by 0x401AECD: _dl_start (in /lib64/ld-linux-x86-64.so.2)
==9030== by 0x4019D17: ??? (in /lib64/ld-linux-x86-64.so.2)
==9030== Your program just tried to execute an instruction that Valgrind
==9030== did not recognise. There are two possible reasons for this.
==9030== 1. Your program has a bug and erroneously jumped to a non-code
==9030== location. If you are running Memcheck and you just saw a
==9030== warning about a bad jump, it's probably your program's fault.
==9030== 2. The instruction is legitimate but Valgrind doesn't handle it,
==9030== i.e. it's Valgrind's fault. If you think this is the case or
==9030== you are not sure, please let us know and we'll try to fix it.
==9030== Either way, Valgrind will now raise a SIGILL signal which will
==9030== probably kill your program.
==9030==
==9030== Process terminating with default action of signal 4 (SIGILL)
==9030== Illegal opcode at address 0x40149D7
==9030== at 0x40149D7: get_common_indices.constprop.0 (in /lib64/ld-linux-x86-64.so.2)
==9030== by 0x401604E: init_cpu_features.constprop.0 (in /lib64/ld-linux-x86-64.so.2)
==9030== by 0x4016360: _dl_x86_init_cpu_features (in /lib64/ld-linux-x86-64.so.2)
==9030== by 0x401974B: _dl_sysdep_start (in /lib64/ld-linux-x86-64.so.2)
==9030== by 0x401AECD: _dl_start (in /lib64/ld-linux-x86-64.so.2)
==9030== by 0x4019D17: ??? (in /lib64/ld-linux-x86-64.so.2)
==9030==
==9030== HEAP SUMMARY:
==9030== in use at exit: 0 bytes in 0 blocks
==9030== total heap usage: 0 allocs, 0 frees, 0 bytes allocated
==9030==
==9030== All heap blocks were freed -- no leaks are possible
==9030==
==9030== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
|
What are my options? How do I fix it?
Valgrind was installed from the official repo and so is gcc.
Thank you for any pointers.
Moderator note: Fixed topic title typo. -- Banana |
|
| Back to top |
|
 |
bstaletic
Guru
Joined: 05 Apr 2014
Posts: 463
|
| Posted: Mon Dec 30, 2024 7:16 am Post subject: |
|
|
Did you compile valgrind/gcc/glibc yourself, or did you use a binhost?
Illegal instruction is most often the result of compiling an ELF for a CPU that has some instructions that your CPU does not. |
|
| Back to top |
|
|
ONEEYEMAN
Advocate
Joined: 01 Mar 2005
Posts: 3674
|
| Posted: Mon Dec 30, 2024 10:06 am Post subject: |
|
|
Hi,
None of the packages mentioned were compiled by hand.
Thank you. |
|
| Back to top |
|
|
sam_
Developer
Joined: 14 Aug 2020
Posts: 2113
|
| Posted: Mon Dec 30, 2024 1:30 pm Post subject: |
|
|
Valgrind will raise SIGILL if it cannot decode some instructions, it says that in the output.
See https://bugs.kde.org/show_bug.cgi?id=381819. You need to build glibc and friends without whatever that extension is (BMI?). You could also try one of the patches attached at the end of that bug for Valgrind. |
|
| Back to top |
|
|
Hu
Administrator
Joined: 06 Mar 2007
Posts: 23064
|
| Posted: Mon Dec 30, 2024 3:54 pm Post subject: |
|
|
BMI looks like a good guess to me, though it could also be tbm: | Code: | $ cat a.s
.text
.byte 0x8F, 0xEA, 0x78, 0x10, 0xD0, 0x8, 0x4, 0x0, 0x0, 0x89
$ as a.s -o a.o
$ command objdump --wide -d a.o
a.o: file format elf64-x86-64
Disassembly of section .text:
0000000000000000 <.text>:
0: 8f ea 78 10 d0 08 04 00 00 bextr $0x408,%eax,%edx
|
| info gcc: | The following built-in functions are available when ‘-mbmi’ is used.
All of them generate the machine instruction that is part of the name.
unsigned int __builtin_ia32_bextr_u32(unsigned int, unsigned int);
unsigned long long __builtin_ia32_bextr_u64 (unsigned long long, unsigned \
long long);
The following built-in functions are available when ‘-mtbm’ is used.
Both of them generate the immediate form of the bextr machine
instruction.
unsigned int __builtin_ia32_bextri_u32 (unsigned int,
const unsigned int);
unsigned long long __builtin_ia32_bextri_u64 (unsigned long long,
const unsigned long long); |
| a.cpp: | unsigned bextr32(unsigned b, unsigned c) { return __builtin_ia32_bextr_u32(b, c); }
unsigned long bextr64(unsigned long b, unsigned long c) { return __builtin_ia32_bextr_u64(b, c); }
unsigned bextri32(unsigned b) { return __builtin_ia32_bextri_u32(b, 0x408); }
unsigned long bextri64(unsigned long b) { return __builtin_ia32_bextri_u64(b, 0x408); }
|
| $ gcc -g0 -mbmi -mtbm -O2 -S -o - a.cpp | c++filt | grep -v -e '^\s*\.' -e '^[0-9]:$': | bextr32(unsigned int, unsigned int):
endbr64
bextr %esi, %edi, %eax
ret
bextr64(unsigned long, unsigned long):
endbr64
bextr %rsi, %rdi, %rax
ret
bextri32(unsigned int):
endbr64
bextr $1032, %edi, %eax
ret
bextri64(unsigned long):
endbr64
bextr $1032, %rdi, %rax
ret
|
|
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
Portage & Programming
