Bug 138702 - vex amd64->IR: unhandled instruction bytes: 0xF0 0xF 0xC0 0x90
Summary: vex amd64->IR: unhandled instruction bytes: 0xF0 0xF 0xC0 0x90
Status: RESOLVED DUPLICATE of bug 158744
Alias: None
Product: valgrind
Classification: Developer tools
Component: vex (show other bugs)
Version: unspecified
Platform: openSUSE Linux
: NOR crash
Target Milestone: ---
Assignee: Julian Seward
Depends on:
Blocks: 253451
  Show dependency treegraph
Reported: 2006-12-12 07:41 UTC by Nick Xie
Modified: 2011-08-11 09:19 UTC (History)
2 users (show)

See Also:
Latest Commit:
Version Fixed In:


Note You need to log in before you can comment on or make changes to this bug.
Description Nick Xie 2006-12-12 07:41:43 UTC
Version:            (using KDE KDE 3.5.5)
Installed from:    SuSE RPMs
Compiler:          GCC 3.3.3 
OS:                Linux

vex amd64->IR: unhandled instruction bytes: 0xF0 0xF 0xC0 0x90 
Your program just tried to execute an instruction that Valgrind 
==8113== did not recognise.  There are two possible reasons for this. 
==8113== 1. Your program has a bug and erroneously jumped to a non-code 
==8113==    location.  If you are running Memcheck and you just saw a 
==8113==    warning about a bad jump, it's probably your program's fault. 
==8113== 2. The instruction is legitimate but Valgrind doesn't handle it, 
==8113==    i.e. it's Valgrind's fault.  If you think this is the case or 
==8113==    you are not sure, please let us know. 
==8113== Either way, Valgrind will now raise a SIGILL signal which will 
==8113== probably kill your program. 
exception dump: 
    program name: ctl 
    signal received: 4 
  context record: 
  exception record: 
    sig/code 0x4/0x1 (SIGILL: ILL_ILLOPC) 
    addr 0x0000000004b57ae9
Comment 1 Nick Xie 2006-12-21 18:36:09 UTC
seems to be the lock xadd %dl,0xb5(%rax)

valgrind output :
==9409== Process terminating with default action of signal 4 (SIGILL): dumping core
==9409==  Illegal opcode at address 0x4B56A36
#0  0x00000000055e3ca9 in ioctl () from /lib64/tls/libc.so.6
(gdb) x/i 0x4B56A36
0x4b56a36 <gdolock+198>:        lock xadd %dl,0xb5(%rax)
(gdb) x/x 0x4B56A36
0x4b56a36 <gdolock+198>:        0x90c00ff0
Comment 2 Tom Hughes 2011-08-11 09:19:19 UTC

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