*** This bug has been marked as a duplicate of bug 393351 ***

(In reply to Tom Hughes from comment #1)
> 
> *** This bug has been marked as a duplicate of bug 393351 ***

only first two bytes match

`unhandled instruction bytes: 0x62 0xF1 0x7D 0x48 0xEF 0xC0 0xC5 0xFB 0x11 0x40`

reproduce on Debian 9 with rocksdb db_bench
git clone https://github.com/facebook/rocksdb.git
cd rocksdb
mkdir build
cd build
cmake ..
make -j
valgrind ./db_bench

root@n18-065-078:~/open_source/rocksdb/build# valgrind ./db_bench
==1607038== Memcheck, a memory error detector
==1607038== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==1607038== Using Valgrind-3.14.0 and LibVEX; rerun with -h for copyright info
==1607038== Command: ./db_bench
==1607038==
vex amd64->IR: unhandled instruction bytes: 0x62 0xF1 0x7D 0x48 0xEF 0xC0 0xC5 0xFB 0x11 0x40
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
==1607038== valgrind: Unrecognised instruction at address 0x5a33409.
==1607038==    at 0x5A33409: rocksdb::AdvancedColumnFamilyOptions::AdvancedColumnFamilyOptions() (in /root/open_source/rocksdb/build/librocksdb.so.6.6.0)
==1607038==    by 0x5A33C43: rocksdb::ColumnFamilyOptions::ColumnFamilyOptions() (in /root/open_source/rocksdb/build/librocksdb.so.6.6.0)
==1607038==    by 0x5A45CA7: __static_initialization_and_destruction_0(int, int) (in /root/open_source/rocksdb/build/librocksdb.so.6.6.0)
==1607038==    by 0x5A484D9: _GLOBAL__sub_I_options_helper.cc (in /root/open_source/rocksdb/build/librocksdb.so.6.6.0)
==1607038==    by 0x400F799: call_init.part.0 (dl-init.c:72)
==1607038==    by 0x400F8AA: call_init (dl-init.c:30)
==1607038==    by 0x400F8AA: _dl_init (dl-init.c:120)
==1607038==    by 0x4000C59: ??? (in /lib/x86_64-linux-gnu/ld-2.24.so)
==1607038== Your program just tried to execute an instruction that Valgrind
==1607038== did not recognise.  There are two possible reasons for this.
==1607038== 1. Your program has a bug and erroneously jumped to a non-code
==1607038==    location.  If you are running Memcheck and you just saw a
==1607038==    warning about a bad jump, it's probably your program's fault.
==1607038== 2. The instruction is legitimate but Valgrind doesn't handle it,
==1607038==    i.e. it's Valgrind's fault.  If you think this is the case or
==1607038==    you are not sure, please let us know and we'll try to fix it.
==1607038== Either way, Valgrind will now raise a SIGILL signal which will
==1607038== probably kill your program.
==1607038==
==1607038== Process terminating with default action of signal 4 (SIGILL): dumping core
==1607038==  Illegal opcode at address 0x5A33409
==1607038==    at 0x5A33409: rocksdb::AdvancedColumnFamilyOptions::AdvancedColumnFamilyOptions() (in /root/open_source/rocksdb/build/librocksdb.so.6.6.0)
==1607038==    by 0x5A33C43: rocksdb::ColumnFamilyOptions::ColumnFamilyOptions() (in /root/open_source/rocksdb/build/librocksdb.so.6.6.0)
==1607038==    by 0x5A45CA7: __static_initialization_and_destruction_0(int, int) (in /root/open_source/rocksdb/build/librocksdb.so.6.6.0)
==1607038==    by 0x5A484D9: _GLOBAL__sub_I_options_helper.cc (in /root/open_source/rocksdb/build/librocksdb.so.6.6.0)
==1607038==    by 0x400F799: call_init.part.0 (dl-init.c:72)
==1607038==    by 0x400F8AA: call_init (dl-init.c:30)
==1607038==    by 0x400F8AA: _dl_init (dl-init.c:120)
==1607038==    by 0x4000C59: ??? (in /lib/x86_64-linux-gnu/ld-2.24.so)
==1607038==
==1607038== HEAP SUMMARY:
==1607038==     in use at exit: 92,064 bytes in 1,424 blocks
==1607038==   total heap usage: 1,967 allocs, 543 frees, 180,484 bytes allocated
==1607038==
==1607038== LEAK SUMMARY:
==1607038==    definitely lost: 0 bytes in 0 blocks
==1607038==    indirectly lost: 0 bytes in 0 blocks
==1607038==      possibly lost: 0 bytes in 0 blocks
==1607038==    still reachable: 92,064 bytes in 1,424 blocks
==1607038==         suppressed: 0 bytes in 0 blocks
==1607038== Rerun with --leak-check=full to see details of leaked memory
==1607038==
==1607038== For counts of detected and suppressed errors, rerun with: -v
==1607038== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
Illegal instruction (core dumped)

Right but 0x62 is a single byte instruction so only the first byte matters...

This bug has been reported 5 times in the past year, as bug numbers 393351,
409999, 414944, 411303 and 414053.  I would like to fix it.  I tried the
steps-to-reproduce shown in bugs 393351 and 414053, but without success: I
can't reproduce it either with the trunk or with 3.15.0.

Without being able to reproduce it, I can't fix it.  The first unhandled byte,
0x62, isn't the start of any known instruction (in 64-bit mode), so I suspect
there has been some failure earlier on.  Maybe Valgrind's instruction decoder
lost track of where it was on the previous instruction.  That's just a guess,
though.

What would be really helpful is if someone could reproduce the failure, and
then use objdump -d to show the instructions around the failure point.  I can
give guidance on how to use objdump if that helps.  If you want to try this, I
suggest you first reproduce the failure while giving --demangle=no
--sym-offsets=yes to Valgrind.  That will make it much easier to relate the
stack trace that Valgrind produces at the failure point, to the output of
objdump -d.