running valgrinded on /bin/bash I get an illegal jump message and a segmentation fault error message. Reproducible: Always Steps to Reproduce: 1. valgrind -v /bin/bash Actual Results: ==21585== Memcheck, a memory error detector ==21585== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al. ==21585== Using Valgrind-3.9.0 and LibVEX; rerun with -h for copyright info ==21585== Command: /bin/bash ==21585== --21585-- Valgrind options: --21585-- -v --21585-- Contents of /proc/version: --21585-- Linux version 3.12.0-gentoo (root@starvald_emeralian) (gcc version 4.8.1 (Gentoo 4.8.1-r1 p1.2, pie-0.5.7) ) #1 SMP PREEMPT Tue Nov 5 12:16:32 EST 2013 --21585-- Arch and hwcaps: AMD64, amd64-cx16-lzcnt-rdtscp-sse3-avx-bmi --21585-- Page sizes: currently 4096, max supported 4096 --21585-- Valgrind library directory: /usr/lib64/valgrind --21585-- Reading syms from /bin/bash --21585-- object doesn't have a symbol table --21585-- Reading syms from /lib64/ld-2.15.so --21585-- Considering /usr/lib/debug/lib64/ld-2.15.so.debug .. --21585-- .. CRC is valid --21585-- Reading syms from /usr/lib64/valgrind/memcheck-amd64-linux --21585-- object doesn't have a symbol table --21585-- object doesn't have a dynamic symbol table --21585-- Scheduler: using generic scheduler lock implementation. --21585-- Reading suppressions file: /usr/lib64/valgrind/default.supp ==21585== embedded gdbserver: reading from /tmp/vgdb-pipe-from-vgdb-to-21585-by-salamanderrake-on-??? ==21585== embedded gdbserver: writing to /tmp/vgdb-pipe-to-vgdb-from-21585-by-salamanderrake-on-??? ==21585== embedded gdbserver: shared mem /tmp/vgdb-pipe-shared-mem-vgdb-21585-by-salamanderrake-on-??? ==21585== ==21585== TO CONTROL THIS PROCESS USING vgdb (which you probably ==21585== don't want to do, unless you know exactly what you're doing, ==21585== or are doing some strange experiment): ==21585== /usr/lib64/valgrind/../../bin/vgdb --pid=21585 ...command... ==21585== ==21585== TO DEBUG THIS PROCESS USING GDB: start GDB like this ==21585== /path/to/gdb /bin/bash ==21585== and then give GDB the following command ==21585== target remote | /usr/lib64/valgrind/../../bin/vgdb --pid=21585 ==21585== --pid is optional if only one valgrind process is running ==21585== --21585-- REDIR: 0x40180b0 (strlen) redirected to 0x380682f1 (???) --21585-- Reading syms from /usr/lib64/valgrind/vgpreload_core-amd64-linux.so --21585-- object doesn't have a symbol table --21585-- Reading syms from /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so --21585-- object doesn't have a symbol table --21585-- REDIR: 0x4017f20 (index) redirected to 0x4c2d1e0 (index) --21585-- REDIR: 0x4017fa0 (strcmp) redirected to 0x4c2e340 (strcmp) --21585-- Reading syms from /lib64/libreadline.so.6.2 --21585-- object doesn't have a symbol table --21585-- Reading syms from /lib64/libncurses.so.5.9 --21585-- object doesn't have a symbol table --21585-- Reading syms from /lib64/libdl-2.15.so --21585-- Considering /usr/lib/debug/lib64/libdl-2.15.so.debug .. --21585-- .. CRC is valid --21585-- Reading syms from /lib64/libc-2.15.so --21585-- Considering /usr/lib/debug/lib64/libc-2.15.so.debug .. --21585-- .. CRC is valid vex amd64->IR: unhandled instruction bytes: 0x8F 0xEA 0xF8 0x10 0xCE 0x3 0x1D 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 ==21585== valgrind: Unrecognised instruction at address 0x40116f6. ==21585== at 0x40116F6: _dl_allocate_tls_storage (in /lib64/ld-2.15.so) ==21585== by 0x4000FCB: init_tls (in /lib64/ld-2.15.so) ==21585== by 0x4003AAE: dl_main (in /lib64/ld-2.15.so) ==21585== by 0x4014F0B: _dl_sysdep_start (in /lib64/ld-2.15.so) ==21585== by 0x4004D0B: _dl_start (in /lib64/ld-2.15.so) ==21585== by 0x4001467: ??? (in /lib64/ld-2.15.so) ==21585== Your program just tried to execute an instruction that Valgrind ==21585== did not recognise. There are two possible reasons for this. ==21585== 1. Your program has a bug and erroneously jumped to a non-code ==21585== location. If you are running Memcheck and you just saw a ==21585== warning about a bad jump, it's probably your program's fault. ==21585== 2. The instruction is legitimate but Valgrind doesn't handle it, ==21585== i.e. it's Valgrind's fault. If you think this is the case or ==21585== you are not sure, please let us know and we'll try to fix it. ==21585== Either way, Valgrind will now raise a SIGILL signal which will ==21585== probably kill your program. ==21585== ==21585== Process terminating with default action of signal 4 (SIGILL) ==21585== Illegal opcode at address 0x40116F6 ==21585== at 0x40116F6: _dl_allocate_tls_storage (in /lib64/ld-2.15.so) ==21585== by 0x4000FCB: init_tls (in /lib64/ld-2.15.so) ==21585== by 0x4003AAE: dl_main (in /lib64/ld-2.15.so) ==21585== by 0x4014F0B: _dl_sysdep_start (in /lib64/ld-2.15.so) ==21585== by 0x4004D0B: _dl_start (in /lib64/ld-2.15.so) ==21585== by 0x4001467: ??? (in /lib64/ld-2.15.so) ==21585== Jump to the invalid address stated on the next line ==21585== at 0x5F6: ??? ==21585== Address 0x5f6 is not stack'd, malloc'd or (recently) free'd ==21585== ==21585== ==21585== Process terminating with default action of signal 11 (SIGSEGV) ==21585== Bad permissions for mapped region at address 0x5F6 ==21585== at 0x5F6: ??? ==21585== ==21585== HEAP SUMMARY: ==21585== in use at exit: 0 bytes in 0 blocks ==21585== total heap usage: 0 allocs, 0 frees, 0 bytes allocated ==21585== ==21585== All heap blocks were freed -- no leaks are possible ==21585== ==21585== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 2 from 2) ==21585== ==21585== 1 errors in context 1 of 1: ==21585== Jump to the invalid address stated on the next line ==21585== at 0x5F6: ??? ==21585== Address 0x5f6 is not stack'd, malloc'd or (recently) free'd ==21585== --21585-- --21585-- used_suppression: 2 dl-hack3-cond-1 /usr/lib64/valgrind/default.supp:1196 ==21585== ==21585== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 2 from 2) Segmentation fault Expected Results: Memory messages without a segfault. gentoo am64 on a asus sabertooth 990fx v2.0 mobo with an amd 8350 processor. system built with -march=native -O2 -pipe CFLAGS/CXXFLAGS gcc -v Using built-in specs. COLLECT_GCC=/usr/x86_64-pc-linux-gnu/gcc-bin/4.8.1/gcc COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-pc-linux-gnu/4.8.1/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: /var/tmp/portage/sys-devel/gcc-4.8.1-r1/work/gcc-4.8.1/configure --prefix=/usr --bindir=/usr/x86_64-pc-linux-gnu/gcc-bin/4.8.1 --includedir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.8.1/include --datadir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.8.1 --mandir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.8.1/man --infodir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.8.1/info --with-gxx-include-dir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.8.1/include/g++-v4 --host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --disable-altivec --disable-fixed-point --without-cloog --disable-lto --enable-nls --without-included-gettext --with-system-zlib --enable-obsolete --disable-werror --enable-secureplt --enable-multilib --with-multilib-list=m32,m64 --enable-libmudflap --disable-libssp --enable-libgomp --with-python-dir=/share/gcc-data/x86_64-pc-linux-gnu/4.8.1/python --enable-checking=release --disable-libgcj --enable-libstdcxx-time --enable-languages=c,c++,fortran --enable-shared --enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu --enable-targets=all --with-bugurl=http://bugs.gentoo.org/ --with-pkgversion='Gentoo 4.8.1-r1 p1.2, pie-0.5.7' Thread model: posix gcc version 4.8.1 (Gentoo 4.8.1-r1 p1.2, pie-0.5.7) glibc-2.15-r3
*** This bug has been marked as a duplicate of bug 323431 ***
My bug has nothing to do with compiling with -O2 since I tried to compile my own app with out the -O2 flag
The compiler flags are irrelevant, except in so much as they will influence what instructions the compiler chooses. In this case it's the -march=native that is important. The problem is that your compiler is choosing to use an AMD specific instruction that valgrind does not currently support.
Ok, is there a flag to test to see which one is causing the issue?
Which instruction you mean? You're already told us that with the "unhandled instruction bytes" message, which is why I closed this as a dup because it's the same vpcmov instruction as the other bug.
I mean which gcc flag I could disable to see which one is the culprit, which one of the msse flags.
Just change -march=native to something more restrictive lime -march=k8-sse3. That's pretty conservative, so you can probably try moving up some more generations but you need to avoid any of the recent AMD extensions.
With this compiler output I still get the same message as before. ``` 13:48:17: Running steps for project cxxprimerx11... 13:48:17: Configuration unchanged, skipping qmake step. 13:48:17: Starting: "/usr/bin/make" g++ -c -pipe -std=c++11 -march=k8-sse3 -Wall -W -fPIE -I/usr/lib64/qt5/mkspecs/linux-g++ -I../../../cxxprimerx11 -I. -o main.o ../../../cxxprimerx11/main.cpp ../../../cxxprimerx11/main.cpp:40:5: warning: unused parameter 'argv' [-Wunused-parameter] int main(int argv, char *argc[]) { ^ ../../../cxxprimerx11/main.cpp:40:5: warning: unused parameter 'argc' [-Wunused-parameter] g++ -c -pipe -std=c++11 -march=k8-sse3 -Wall -W -fPIE -I/usr/lib64/qt5/mkspecs/linux-g++ -I../../../cxxprimerx11 -I. -o Sales_data.o ../../../cxxprimerx11/Sales_data.cpp g++ -c -pipe -std=c++11 -march=k8-sse3 -Wall -W -fPIE -I/usr/lib64/qt5/mkspecs/linux-g++ -I../../../cxxprimerx11 -I. -o ch03.o ../../../cxxprimerx11/ch03.cpp g++ -Wl,-O1 -o cxxprimerx11 main.o Sales_data.o ch03.o 13:48:18: The process "/usr/bin/make" exited normally. 13:48:18: Elapsed time: 00:01. ```