Bug 577590 - valgrind doesn't recognize sse2 instructions
valgrind doesn't recognize sse2 instructions
Status: CLOSED DUPLICATE of bug 574889
Product: Fedora
Classification: Fedora
Component: valgrind (Show other bugs)
rawhide
All Linux
low Severity medium
: ---
: ---
Assigned To: Jakub Jelinek
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2010-03-28 02:28 EDT by Ben Boeckel
Modified: 2010-04-04 10:07 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2010-04-04 10:07:41 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Ben Boeckel 2010-03-28 02:28:05 EDT
Description of problem:
Valgrind raises a SIGILL when an sse2 instruction on Fedora 13 i686. Since it hasn't been rebuilt since F12, it probably just needs rebuilt to work again. Unfortunately, no x86_64 machines (yet) with F13 to test there.

Version-Release number of selected component (if applicable):
valgrind-3.5.0-14.fc12.i686

How reproducible:
Always.

Steps to Reproduce:
 vex x86->IR: unhandled instruction bytes: 0x66 0x66 0x2E 0xF
 ==19334== valgrind: Unrecognised instruction at address 0x4351bd5.
 ==19334== Your program just tried to execute an instruction that Valgrind
 ==19334== did not recognise.  There are two possible reasons for this.
 ==19334== 1. Your program has a bug and erroneously jumped to a non-code
 ==19334==    location.  If you are running Memcheck and you just saw a
 ==19334==    warning about a bad jump, it's probably your program's fault.
 ==19334== 2. The instruction is legitimate but Valgrind doesn't handle it,
 ==19334==    i.e. it's Valgrind's fault.  If you think this is the case or
 ==19334==    you are not sure, please let us know and we'll try to fix it.
 ==19334== Either way, Valgrind will now raise a SIGILL signal which will
 ==19334== probably kill your program
 ==19334== 
 ==19334== Process terminating with default action of signal 4 (SIGILL)
 ==19334==  Illegal opcode at address 0x4351BD5
 ==19334==    at 0x4351BD5: __memset_sse2 (in /lib/libc-2.11.90.so)
 ==19334==    by 0x4656252: PR_CallOnce (in /lib/libnspr4.so)
 ==19334==    by 0x459B47B: ??? (in /lib/libfreebl3.so)
 ==19334==    by 0x457A55A: ??? (in /lib/libfreebl3.so)
 ==19334==    by 0x460BC62: ??? (in /usr/lib/libsoftokn3.so)
 ==19334==    by 0x45EDE81: ??? (in /usr/lib/libsoftokn3.so)
 ==19334==    by 0x45EE12D: ??? (in /usr/lib/libsoftokn3.so)
 ==19334==    by 0x4465592: ??? (in /usr/lib/libnss3.so)
 ==19334==    by 0x4465E72: ??? (in /usr/lib/libnss3.so)
 ==19334==    by 0x447A01E: SECMOD_LoadModule (in /usr/lib/libnss3.so)
 ==19334==    by 0x447A19E: SECMOD_LoadModule (in /usr/lib/libnss3.so)
 ==19334==    by 0x4446002: ??? (in /usr/lib/libnss3.so)
Comment 1 Ben Boeckel 2010-03-28 02:48:31 EDT
A scratch build didn't help. This is something deeper than just a rebuild.
Comment 2 Kamil Dudka 2010-04-04 10:07:41 EDT

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

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