Bug 150408 - vex amd64->IR: unhandled instruction bytes: 0x66 0x66 0x66 0x66
Summary: vex amd64->IR: unhandled instruction bytes: 0x66 0x66 0x66 0x66
Status: RESOLVED DUPLICATE of bug 148447
Alias: None
Product: valgrind
Classification: Developer tools
Component: memcheck (show other bugs)
Version: unspecified
Platform: Unlisted Binaries Linux
: NOR normal
Target Milestone: ---
Assignee: Julian Seward
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2007-10-02 12:38 UTC by Jos van den Oever
Modified: 2007-10-02 12:59 UTC (History)
0 users

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Jos van den Oever 2007-10-02 12:38:38 UTC
I'm debugging Strigi on an intel 64 cpu (q6600) on ubuntu gutsy. The valgrind 
version is valgrind-3.2.3-Debian.
The program runs mostly ok, but when run in valgrind, it immediately throws the 
error I pasted below. I've no idea if this is a legitimate instruction or not.

The program i'm debuggin was compiled with gcc 4.1.3.

==28600== Memcheck, a memory error detector.
==28600== Copyright (C) 2002-2007, and GNU GPL'd, by Julian Seward et al.
==28600== Using LibVEX rev 1732, a library for dynamic binary translation.
==28600== Copyright (C) 2004-2007, and GNU GPL'd, by OpenWorks LLP.
==28600== Using valgrind-3.2.3-Debian, a dynamic binary instrumentation 
framework.
==28600== Copyright (C) 2000-2007, and GNU GPL'd, by Julian Seward et al.
==28600== For more details, rerun with: -v
==28600==
vex amd64->IR: unhandled instruction bytes: 0x66 0x66 0x66 0x66
==28600== valgrind: Unrecognised instruction at address 0x4016321.
==28600== Your program just tried to execute an instruction that Valgrind
==28600== did not recognise.  There are two possible reasons for this.
==28600== 1. Your program has a bug and erroneously jumped to a non-code
==28600==    location.  If you are running Memcheck and you just saw a
==28600==    warning about a bad jump, it's probably your program's fault.
==28600== 2. The instruction is legitimate but Valgrind doesn't handle it,
==28600==    i.e. it's Valgrind's fault.  If you think this is the case or
==28600==    you are not sure, please let us know and we'll try to fix it.
==28600== Either way, Valgrind will now raise a SIGILL signal which will
==28600== probably kill your program.
==28600==
==28600== Process terminating with default action of signal 4 (SIGILL)
==28600==  Illegal opcode at address 0x4016321
==28600==    at 0x4016321: (within /lib/ld-2.6.1.so)
==28600==    by 0x4007CC2: (within /lib/ld-2.6.1.so)
==28600==    by 0x4003329: (within /lib/ld-2.6.1.so)
==28600==    by 0x4014457: (within /lib/ld-2.6.1.so)
==28600==    by 0x400230A: (within /lib/ld-2.6.1.so)
==28600==    by 0x4000A67: (within /lib/ld-2.6.1.so)
==28600==
==28600== ---- Attach to debugger ? --- [Return/N/n/Y/y/C/c] ---- n
==28600==
==28600== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
==28600== malloc/free: in use at exit: 0 bytes in 0 blocks.
==28600== malloc/free: 0 allocs, 0 frees, 0 bytes allocated.
==28600== For counts of detected errors, rerun with: -v
==28600== All heap blocks were freed -- no leaks are possible.
Comment 1 Jos van den Oever 2007-10-02 12:40:42 UTC
There is another report on it here:
http://www.mail-archive.com/debian-bugs-dist%40lists.debian.org/msg379539.html
Comment 2 Jos van den Oever 2007-10-02 12:59:09 UTC

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