Bug 189232 - Illegal opcode - unhandled instruction bytes: 0xCB 0x55 0x8B 0xEC
Summary: Illegal opcode - unhandled instruction bytes: 0xCB 0x55 0x8B 0xEC
Status: REPORTED
Alias: None
Product: valgrind
Classification: Developer tools
Component: general (show other bugs)
Version: 3.4.1
Platform: RedHat Enterprise Linux Linux
: NOR crash (vote)
Target Milestone: ---
Assignee: Julian Seward
URL:
Keywords:
Depends on:
Blocks: 256630
  Show dependency treegraph
 
Reported: 2009-04-09 18:16 UTC by esutton
Modified: 2010-11-11 20:13 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 esutton 2009-04-09 18:16:27 UTC
I believe the opcode is valid but perhaps not on the Intel Xeon quad-core that I am developing on.  My application uses a closed-source video decoder made by Pegasus ( libpicl20.so ).  This decoder supports multiple machine architectures so that at run-time it can select the best performing machine instructions to use.  Is there a work-around to tell Valgrind to skip libpicl20.so? 


libFesVideo Version: 0.0.683
               Date: 4/9/2009 10:44AM
Adding Connections...
Selecting Starboard Camera...
Show window
SDL_Init...
vex x86->IR: unhandled instruction bytes: 0xCB 0x55 0x8B 0xEC
==9455== Process terminating with default action of signal 4 (SIGILL): dumping core
==9455==  Illegal opcode at address 0x7B3ABB5
==9455==    at 0x7B3ABB5: ???
==9455==    by 0x407A2BE: picosCallPegasusProc (in /home/esutton/sys/bin/libpicl20.so)
==9455==    by 0x4074724: (within /home/esutton/sys/bin/libpicl20.so)
==9455==    by 0x407491E: (within /home/esutton/sys/bin/libpicl20.so)
==9455==    by 0x40798DD: threadfn (in /home/esutton/sys/bin/libpicl20.so)
==9455==    by 0x41C45A: start_thread (in /lib/libpthread-2.5.so)
==9455==    by 0x373C4D: clone (in /lib/libc-2.5.so)

Thanks for a great tool and thanks in advance for your help,

-Ed
Comment 1 Tom Hughes 2009-04-09 19:13:16 UTC
Well 0xCB appears to be a FAR RET instruction, which is pretty obscure. It's not new though - it's an ancient artefact of 16 bit days.