Bug 203273 - vex amd64->IR: unhandled instruction bytes: 0x66 0xF 0x1F 0x44
vex amd64->IR: unhandled instruction bytes: 0x66 0xF 0x1F 0x44
Product: Fedora
Classification: Fedora
Component: valgrind (Show other bugs)
x86_64 Linux
medium Severity medium
: ---
: ---
Assigned To: Jakub Jelinek
Depends On:
  Show dependency treegraph
Reported: 2006-08-20 06:25 EDT by Caolan McNamara
Modified: 2007-11-30 17:11 EST (History)
0 users

See Also:
Fixed In Version: 3.2.0-5
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2006-08-21 07:13:03 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Caolan McNamara 2006-08-20 06:25:09 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20060808 Fedora/ Firefox/ 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
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== 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== 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):

How reproducible:

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 07:13:03 EDT
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.