Bug 760262

Summary: valgrind errors when using crypt() or crypt_r() when compiled for 64bit
Product: [Fedora] Fedora Reporter: Lars Gullik Bjønnes <larsbj>
Component: glibcAssignee: Jeff Law <law>
Status: CLOSED NOTABUG QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: unspecified    
Version: 16CC: fweimer, hgb, jakub, law, schwab, tiomiguel
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2012-02-06 23:15:56 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Attachments:
Description Flags
Test prog for showing problem none

Description Lars Gullik Bjønnes 2011-12-05 17:39:47 UTC
Created attachment 541034 [details]
Test prog for showing problem

Description of problem:

  When running the attached program under valgrind it gives
  errors.

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

  glibc-2.14.90-19.x86_64


How reproducible:
  Every time, when compiled with -m64
  with -m32 the errors goes away.

Steps to Reproduce:
1. compile the attached program with gcc -m64 -lcrypt crypt_r.c
2. run it with valgrind ./a.out "$1$abcdef$"
   (In the above string $1$ can be substituted with $5$ or $6$
    and will then point to same errors,
    but with sha256 and sha512 instead of md5)
  
Actual results:
   Valgrind gives erorrs about conditional jumps depending
   on uninitialized value(s)

Expected results:
   No errors.

Comment 1 Lars Gullik Bjønnes 2011-12-06 00:51:04 UTC
I am not been able to reproduce this on AMD Phenom(tm) II,
I have only seen it on Intel so far (i7 970).

Comment 2 Jeff Law 2011-12-06 04:21:33 UTC
It could likely be specific to the SSE2 path which is only going to be used on a specific set of processors.  I'll probably do a test build which forces everything to the SSE2 path so that I can test/debug without needing to find a box with a specific processor variant.

Comment 3 Henrik Bakken 2011-12-06 10:00:17 UTC
The errors I get are:
==9710== Conditional jump or move depends on uninitialised value(s)
==9710==    at 0x33E929624F: __stpncpy_sse2_unaligned (in /lib64/libc-2.14.90.so)
==9710==    by 0x33F4E0208C: __sha256_crypt_r (in /lib64/libcrypt-2.14.90.so)
==9710==    by 0x33F4E00E7F: crypt_r (in /lib64/libcrypt-2.14.90.so)
==9710==    by 0x40063A: main (h.c:12)
==9710== 
==9710== Conditional jump or move depends on uninitialised value(s)
==9710==    at 0x33E92961B8: __stpncpy_sse2_unaligned (in /lib64/libc-2.14.90.so)
==9710==    by 0x33F4E0208C: __sha256_crypt_r (in /lib64/libcrypt-2.14.90.so)
==9710==    by 0x33F4E00E7F: crypt_r (in /lib64/libcrypt-2.14.90.so)
==9710==    by 0x40063A: main (h.c:12)

I've tried to build my own glibc with debug symbols, and I can easily
reproduce it there.  With glibc from git (fedora/2.14/master branch),
valgrind seems to think the error is in

	movslq	(%r11, %rcx,4), %rcx

at line 1106 in strcpy.S in sysdeps/x86_64/multiarch/strcpy.S.

when called by crypt/sha256-crypt.c:307

This is on an Intel core i7.

Comment 4 Jeff Law 2011-12-23 05:22:05 UTC
*** Bug 699917 has been marked as a duplicate of this bug. ***

Comment 5 Jeff Law 2012-02-06 23:15:56 UTC
This is an annoying, but harmless false positive warning.  It's a well known issue with vangrind that occurs with highly optimized string routines utilizing SSE extensions.

In theory it should be possible to suppress this warning, but I've never tried to use the valgrind user defined suppressions.