Bug 760262 - valgrind errors when using crypt() or crypt_r() when compiled for 64bit
Summary: valgrind errors when using crypt() or crypt_r() when compiled for 64bit
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Fedora
Classification: Fedora
Component: glibc
Version: 16
Hardware: x86_64
OS: Linux
unspecified
medium
Target Milestone: ---
Assignee: Jeff Law
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
: 699917 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-12-05 17:39 UTC by Lars Gullik Bjønnes
Modified: 2016-11-24 15:36 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2012-02-06 23:15:56 UTC
Type: ---


Attachments (Terms of Use)
Test prog for showing problem (1.11 KB, text/x-csrc)
2011-12-05 17:39 UTC, Lars Gullik Bjønnes
no flags Details

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.


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