Similar to: https://bugs.kde.org/show_bug.cgi?id=373166 With any utility program: /bin/date /bin/echo ... the following error. The system is 64-bit Intel. I have tested vagrind in 32-bit machine (Intel) and valgrind does not work there either. The bug was not in my code. Version was (the 64-bit bug): $ valgrind --version valgrind-3.10.1 The systems were: CURRENT: $ uname -a # 64-bit (the error) FreeBSD xxxxxxx 12.0-CURRENT FreeBSD 12.0-CURRENT #5 r333605: Wed May 16 13:10:26 EEST 2018 root@xxxxxxxx:/usr/obj/usr/src/amd64.amd64/sys/XXXXXX_64bit amd64 RELEASE: $ uname -a # 32-bit (the latter error) FreeBSD xxxxxxx 11.1-RELEASE-p9 FreeBSD 11.1-RELEASE-p9 #0: Tue Apr 3 16:51:52 UTC 2018 root@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC i386 The systems are under development and the port may have changes to the original. The error looks like the following: _______________________________________ 64-bit: $ valgrind /bin/date ==9140== Memcheck, a memory error detector ==9140== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al. ==9140== Using Valgrind-3.10.1 and LibVEX; rerun with -h for copyright info ==9140== Command: /bin/date ==9140== vex amd64->IR: unhandled instruction bytes: 0xC4 0xE2 0x4D 0x8E 0x10 0xC4 0xC1 0x45 vex amd64->IR: REX=0 REX.W=0 REX.R=0 REX.X=0 REX.B=0 vex amd64->IR: VEX=1 VEX.L=1 VEX.nVVVV=0x6 ESC=0F38 vex amd64->IR: PFX.66=1 PFX.F2=0 PFX.F3=0 ==9140== valgrind: Unrecognised instruction at address 0x4d3c0ae. ==9140== at 0x4D3C0AE: ??? (in /lib/libc.so.7) ==9140== by 0x49249: ??? ==9140== by 0x4D93AB3: ??? (in /lib/libc.so.7) ==9140== by 0x7FEFFF67F: ??? ==9140== by 0x4D90191: ??? (in /lib/libc.so.7) ==9140== by 0x4D917FF: ??? (in /lib/libc.so.7) ==9140== by 0x4E3D7FF: ??? (in /lib/libc.so.7) ==9140== by 0x4828DEF: ??? ==9140== by 0x4E321B1: ??? (in /lib/libc.so.7) ==9140== Your program just tried to execute an instruction that Valgrind ==9140== did not recognise. There are two possible reasons for this. ==9140== 1. Your program has a bug and erroneously jumped to a non-code ==9140== location. If you are running Memcheck and you just saw a ==9140== warning about a bad jump, it's probably your program's fault. ==9140== 2. The instruction is legitimate but Valgrind doesn't handle it, ==9140== i.e. it's Valgrind's fault. If you think this is the case or ==9140== you are not sure, please let us know and we'll try to fix it. ==9140== Either way, Valgrind will now raise a SIGILL signal which will ==9140== probably kill your program. ==9140== ==9140== Process terminating with default action of signal 4 (SIGILL): dumping core ==9140== Illegal opcode at address 0x4D3C0AE ==9140== at 0x4D3C0AE: ??? (in /lib/libc.so.7) ==9140== by 0x49249: ??? ==9140== by 0x4D93AB3: ??? (in /lib/libc.so.7) ==9140== by 0x7FEFFF67F: ??? ==9140== by 0x4D90191: ??? (in /lib/libc.so.7) ==9140== by 0x4D917FF: ??? (in /lib/libc.so.7) ==9140== by 0x4E3D7FF: ??? (in /lib/libc.so.7) ==9140== by 0x4828DEF: ??? ==9140== by 0x4E321B1: ??? (in /lib/libc.so.7) ==9140== ==9140== HEAP SUMMARY: ==9140== in use at exit: 0 bytes in 0 blocks ==9140== total heap usage: 0 allocs, 0 frees, 0 bytes allocated ==9140== ==9140== All heap blocks were freed -- no leaks are possible ==9140== ==9140== For counts of detected and suppressed errors, rerun with: -v ==9140== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0) Illegal instruction _______________________________________ 32-bit: $ valgrind /bin/echo "1" valgrind: I failed to allocate space for the application's stack. valgrind: This may be the result of a very large --main-stacksize= valgrind: setting. Cannot continue. Sorry. $ valgrind /bin/date valgrind: I failed to allocate space for the application's stack. valgrind: This may be the result of a very large --main-stacksize= valgrind: setting. Cannot continue. Sorry.
I don't how it is in any way similar to https://bugs.kde.org/show_bug.cgi?id=373166 other than that both involved unhandled instruction sequences. Even that isn't the whole story because you've really reported two entirely separate bugs here - fortunately only one of them is in scope here. The 64 bit issue appears to be a vpmaskmovd instruction (0x8E with an 0x0F 0x38 prefix from the VEX prefix) which I suspect may be implemented now - certainly some variants of it are. You are using 3.10.0 though which is nearly four years old. The 32 bit issue is almost certainly FreeBSD specific and should be reported to the people maintaining the FreeBSD port which is out of tree and not maintained by us.
32-bit error added to https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=228973 . Unfortunately the version in 12-CURRENT is old. Even older version can be found from an URL: https://bitbucket.org/stass/valgrind-freebsd/overview . Where the ports version is I don't know. Compiling valgrind from source: # ./autogen.sh running: aclocal running: autoheader running: automake -a running: autoconf # sh ./configure --prefix=/usr/local/valgrind checking for a BSD-compatible install... /usr/bin/install -c checking whether build environment is sane... yes checking for a thread-safe mkdir -p... ./install-sh -c -d ... checking for gcc... no checking for cc... cc checking whether the C compiler works... yes ... checking for a supported version of gcc... ok (clang-6.0.0) checking build system type... x86_64-unknown-freebsd12.0 checking host system type... x86_64-unknown-freebsd12.0 checking for a supported CPU... ok (x86_64) checking for a 64-bit only build... no checking for a 32-bit only build... no checking for a supported OS... no (freebsd12.0) configure: error: Valgrind is operating system specific. Sorry.