Bug 203273 - vex amd64->IR: unhandled instruction bytes: 0x66 0xF 0x1F 0x44
Summary: vex amd64->IR: unhandled instruction bytes: 0x66 0xF 0x1F 0x44
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: valgrind
Version: rawhide
Hardware: x86_64
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Jakub Jelinek
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2006-08-20 10:25 UTC by Caolan McNamara
Modified: 2007-11-30 22:11 UTC (History)
0 users

Fixed In Version: 3.2.0-5
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2006-08-21 11:13:03 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description Caolan McNamara 2006-08-20 10:25:09 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.8.0.6) Gecko/20060808 Fedora/1.5.0.6-3 Firefox/1.5.0.6 pango-text

Description of problem:
valgrind /usr/lib64/openoffice.org2.0/program/soffice.bin

->

==17155== Memcheck, a memory error detector.
==17155== Copyright (C) 2002-2006, and GNU GPL'd, by Julian Seward et al.
==17155== Using LibVEX rev 1606, a library for dynamic binary translation.
==17155== Copyright (C) 2004-2006, and GNU GPL'd, by OpenWorks LLP.
==17155== Using valgrind-3.2.0, a dynamic binary instrumentation framework.
==17155== Copyright (C) 2000-2006, and GNU GPL'd, by Julian Seward et al.
==17155== For more details, rerun with: -v
==17155== 
vex amd64->IR: unhandled instruction bytes: 0x66 0xF 0x1F 0x44
==17155== valgrind: Unrecognised instruction at address 0x324D812C2A.
==17155== Your program just tried to execute an instruction that Valgrind
==17155== did not recognise.  There are two possible reasons for this.
==17155== 1. Your program has a bug and erroneously jumped to a non-code
==17155==    location.  If you are running Memcheck and you just saw a
==17155==    warning about a bad jump, it's probably your program's fault.
==17155== 2. The instruction is legitimate but Valgrind doesn't handle it,
==17155==    i.e. it's Valgrind's fault.  If you think this is the case or
==17155==    you are not sure, please let us know and we'll try to fix it.
==17155== Either way, Valgrind will now raise a SIGILL signal which will
==17155== probably kill your program.
==17155== 
==17155== Process terminating with default action of signal 4 (SIGILL)
==17155==  Illegal opcode at address 0x324D812C2A
==17155==    at 0x324D812C2A: _dl_sysdep_start (in /lib64/ld-2.4.90.so)
==17155==    by 0x324D801467: _dl_start (in /lib64/ld-2.4.90.so)
==17155==    by 0x324D800B57: (within /lib64/ld-2.4.90.so)
==17155== 
==17155== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
==17155== malloc/free: in use at exit: 0 bytes in 0 blocks.
==17155== malloc/free: 0 allocs, 0 frees, 0 bytes allocated.
==17155== For counts of detected errors, rerun with: -v
==17155== All heap blocks were freed -- no leaks are possible.
Illegal instruction

Version-Release number of selected component (if applicable):
valgrind-3.2.0-4

How reproducible:
Always


Steps to Reproduce:
1. valgrind /usr/lib64/openoffice.org2.0/program/soffice.bin

Actual Results:


Expected Results:


Additional info:

Comment 1 Jakub Jelinek 2006-08-21 11:13:03 UTC
Should be fixed in valgrind-3.2.0-5.


Note You need to log in before you can comment on or make changes to this bug.