Bug 167700 - vex x86->IR: unhandled instruction bytes: 0xD5 0x36 0x5B 0xC3
Summary: vex x86->IR: unhandled instruction bytes: 0xD5 0x36 0x5B 0xC3
Status: RESOLVED DUPLICATE of bug 256387
Alias: None
Product: valgrind
Classification: Developer tools
Component: vex (show other bugs)
Version: 3.3.1
Platform: Ubuntu Linux
: NOR crash
Target Milestone: ---
Assignee: Julian Seward
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2008-07-30 02:47 UTC by darwin te
Modified: 2010-11-11 18:52 UTC (History)
2 users (show)

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 darwin te 2008-07-30 02:47:04 UTC
Version:           3.3.1 (using KDE 4.1.0)
Installed from:    Ubuntu Packages
OS:                Linux

An unsupported opcode (0xD5??) in Valgrind 3.3.0 and 3.3.1:

E.g.,:

0xD5 0x36 0xx90 x90

8048385 !   aad  36h
8048387 !   nop
8048388 !   nop
8048389 !   nop

Application will run fine without valgrind but causes the following error message under Valgrind:

[local] ~/hello > valgrind ./a.out
==29670== Memcheck, a memory error detector.
==29670== Copyright (C) 2002-2007, and GNU GPL'd, by Julian Seward et al.
==29670== Using LibVEX rev 1804, a library for dynamic binary translation.
==29670== Copyright (C) 2004-2007, and GNU GPL'd, by OpenWorks LLP.
==29670== Using valgrind-3.3.0-Debian, a dynamic binary instrumentation framework.
==29670== Copyright (C) 2000-2007, and GNU GPL'd, by Julian Seward et al.
==29670== For more details, rerun with: -v
==29670==
vex x86->IR: unhandled instruction bytes: 0xD5 0x36 0x90 0x90
==29670== valgrind: Unrecognised instruction at address 0x8048385.
==29670== Your program just tried to execute an instruction that Valgrind
==29670== did not recognise.  There are two possible reasons for this.
==29670== 1. Your program has a bug and erroneously jumped to a non-code
==29670==    location.  If you are running Memcheck and you just saw a
==29670==    warning about a bad jump, it's probably your program's fault.
==29670== 2. The instruction is legitimate but Valgrind doesn't handle it,
==29670==    i.e. it's Valgrind's fault.  If you think this is the case or
==29670==    you are not sure, please let us know and we'll try to fix it.
==29670== Either way, Valgrind will now raise a SIGILL signal which will
==29670== probably kill your program.
==29670==
==29670== Process terminating with default action of signal 4 (SIGILL)
==29670==  Illegal opcode at address 0x8048385
==29670==    at 0x8048385: main (in /home/darwin/hello/a.out)
==29670==
==29670== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 11 from 1)
==29670== malloc/free: in use at exit: 0 bytes in 0 blocks.
==29670== malloc/free: 0 allocs, 0 frees, 0 bytes allocated.
==29670== For counts of detected errors, rerun with: -v
==29670== All heap blocks were freed -- no leaks are possible.
Illegal instruction
Comment 1 Vince Weaver 2010-11-11 18:52:19 UTC

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