Bug 575083

Summary: i686 valgrind raises SIGILL on call of NSS_NoDB_Init()
Product: [Fedora] Fedora Reporter: Kamil Dudka <kdudka>
Component: nssAssignee: Kai Engert (:kaie) (inactive account) <kengert>
Status: CLOSED DUPLICATE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: high    
Version: 13CC: emaldona, kdudka, kengert
Target Milestone: ---Keywords: Regression
Target Release: ---   
Hardware: i686   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2010-03-19 12:17:02 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
minimal example none

Description Kamil Dudka 2010-03-19 12:06:02 UTC
Created attachment 401229 [details]
minimal example

Description of problem:
vex x86->IR: unhandled instruction bytes: 0x66 0x66 0x2E 0xF
==3314== valgrind: Unrecognised instruction at address 0x42a6de5.
==3314== Your program just tried to execute an instruction that Valgrind
==3314== did not recognise.  There are two possible reasons for this.
==3314== 1. Your program has a bug and erroneously jumped to a non-code
==3314==    location.  If you are running Memcheck and you just saw a
==3314==    warning about a bad jump, it's probably your program's fault.
==3314== 2. The instruction is legitimate but Valgrind doesn't handle it,
==3314==    i.e. it's Valgrind's fault.  If you think this is the case or
==3314==    you are not sure, please let us know and we'll try to fix it.
==3314== Either way, Valgrind will now raise a SIGILL signal which will
==3314== probably kill your program.
==3314== 
==3314== Process terminating with default action of signal 4 (SIGILL)
==3314==  Illegal opcode at address 0x42A6DE5
==3314==    at 0x42A6DE5: __memset_sse2 (memset-sse2.S:258)
==3314==    by 0x434A252: PR_CallOnce (prinit.c:807)
==3314==    by 0x488D47B: PR_CallOnce_stub (stubs.c:438)
==3314==    by 0x486C55A: RNG_RNGInit (drbg.c:469)
==3314==    by 0x47BEC62: RNG_RNGInit (loader.c:834)
==3314==    by 0x47A0E81: nsc_CommonInitialize (pkcs11.c:2582)
==3314==    by 0x47A112D: NSC_Initialize (pkcs11.c:2710)
==3314==    by 0x4073592: secmod_ModuleInit (pk11load.c:252)
==3314==    by 0x4073E72: secmod_LoadPKCS11Module (pk11load.c:492)
==3314==    by 0x408801E: SECMOD_LoadModule (pk11pars.c:1108)
==3314==    by 0x408819E: SECMOD_LoadModule (pk11pars.c:1143)
==3314==    by 0x4054002: nss_Init (nssinit.c:461)


Version-Release number of selected component (if applicable):
# rpm -qa nss\*
nss-debuginfo-3.12.6-1.2.fc13.i686
nss-util-devel-3.12.6-1.fc13.i686
nss-softokn-freebl-3.12.4-15.fc13.i686
nss-sysinit-3.12.6-1.2.fc13.i686
nss_db-2.2.3-0.2.pre1.fc13.i686
nss-softokn-3.12.4-15.fc13.i686
nss-devel-3.12.6-1.2.fc13.i686
nss_ldap-264-9.fc13.i686
nss-util-debuginfo-3.12.6-1.fc13.i686
nss-softokn-debuginfo-3.12.4-15.fc13.i686
nss-util-3.12.6-1.fc13.i686
nss-softokn-devel-3.12.4-15.fc13.i686
nss_compat_ossl-0.9.6-1.fc13.i686
nss-3.12.6-1.2.fc13.i686
nss-tools-3.12.6-1.2.fc13.i686

# rpm -q nspr
nspr-4.8.4-2.fc13.i686

# rpm -q valgrind
valgrind-3.5.0-14.fc12.i686

# rpm -q glibc
glibc-2.11.90-15.i686


How reproducible:
100%

Steps to Reproduce:
1. run the attached minimal example

Actual results:
process gets SIGILL

Expected results:
no SIGILL, NSS initialized

Additional info:
The bug breaks F-13 builds of curl:
http://koji.fedoraproject.org/koji/taskinfo?taskID=2061956
http://koji.fedoraproject.org/koji/taskinfo?taskID=2062059

Comment 1 Kamil Dudka 2010-03-19 12:17:02 UTC

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