Bug 626470

Summary: strcasecmp() triggers a valgrind error after update of glibc
Product: [Fedora] Fedora Reporter: Kamil Dudka <kdudka>
Component: valgrindAssignee: Jakub Jelinek <jakub>
Status: CLOSED ERRATA QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: high Docs Contact:
Priority: low    
Version: 14CC: caolanm, dodji, dtardon, erik-fedora, igor.redhat, jakub, jan.kratochvil, schwab
Target Milestone: ---Keywords: Regression
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: curl-7.21.0-6.fc14 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2010-11-17 23:23:07 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:
Bug Depends On:    
Bug Blocks: 631449    
Attachments:
Description Flags
a self contained test case none

Description Kamil Dudka 2010-08-23 16:06:42 UTC 
Description of problem:
 ==4925== Invalid read of size 8
 ==4925==    at 0x5A3C431: __strcasecmp_l_ssse3 (in /lib64/libc-2.12.90.so)
 ==4925==    by 0x506A78E: curl_strequal (strequal.c:37)
 ==4925==    by 0x40A08B: operate (main.c:4775)
 ==4925==    by 0x40D890: main (main.c:5748)
 ==4925==  Address 0x9565ec8 is 8 bytes inside a block of size 14 alloc'd
 ==4925==    at 0x4C2615D: malloc (vg_replace_malloc.c:195)
 ==4925==    by 0x597E581: strdup (in /lib64/libc-2.12.90.so)
 ==4925==    by 0x409EEA: operate (main.c:4729)
 ==4925==    by 0x40D890: main (main.c:5748)


Version-Release number of selected component (if applicable):
glibc-2.12.90-7
valgrind-3.5.0-18


How reproducible:
100%


Steps to Reproduce:
1. build rawhide or f14 curl for x86_64 with valgrind available

  
Additional info:
- x86_64 specific
- the same code was working with glibc-2.12.90-6
- the same code works without valgrind
Comment 1 Kamil Dudka 2010-08-23 19:14:25 UTC 
This way I got x86_64 builds of curl running again on rawhide/f14:

# either glibc's implementation of strcasecmp() or its interpretation
# by valgrind seems to be broken on x86_64 (#626470)
%ifarch x86_64
sed -i 's/HAVE_STRCASECMP/HAVE_BROKEN_STRCASECMP/' lib/curl_config.h
%endif

... but it does not address the root cause.
Comment 2 Andreas Schwab 2010-08-24 13:34:53 UTC 
Please provide a self contained test case.
Comment 3 Kamil Dudka 2010-08-24 14:02:31 UTC 
Created attachment 440660 [details]
a self contained test case
Comment 4 Kamil Dudka 2010-08-24 14:03:53 UTC 
$ curl -sJO https://bugzilla.redhat.com/attachment.cgi?id=440660
$ sh bz626470.c 
==11827== Memcheck, a memory error detector
==11827== Copyright (C) 2002-2009, and GNU GPL'd, by Julian Seward et al.
==11827== Using Valgrind-3.5.0 and LibVEX; rerun with -h for copyright info
==11827== Command: ./a.out
==11827== 
==11827== Invalid read of size 8
==11827==    at 0x4F6B429: __strcasecmp_l_ssse3 (in /lib64/libc-2.12.90.so)
==11827==    by 0x40054A: main (bz626470.c:13)
==11827==  Address 0x51c9040 is 0 bytes inside a block of size 3 alloc'd
==11827==    at 0x4C2615D: malloc (vg_replace_malloc.c:195)
==11827==    by 0x4EAD581: strdup (in /lib64/libc-2.12.90.so)
==11827==    by 0x400525: main (bz626470.c:11)
==11827== 
==11827== Invalid read of size 8
==11827==    at 0x4F6B42D: __strcasecmp_l_ssse3 (in /lib64/libc-2.12.90.so)
==11827==    by 0x40054A: main (bz626470.c:13)
==11827==  Address 0x51c9090 is 0 bytes inside a block of size 3 alloc'd
==11827==    at 0x4C2615D: malloc (vg_replace_malloc.c:195)
==11827==    by 0x4EAD581: strdup (in /lib64/libc-2.12.90.so)
==11827==    by 0x400533: main (bz626470.c:12)
==11827== 
==11827== Invalid read of size 8
==11827==    at 0x4F6B431: __strcasecmp_l_ssse3 (in /lib64/libc-2.12.90.so)
==11827==    by 0x40054A: main (bz626470.c:13)
==11827==  Address 0x51c9048 is 5 bytes after a block of size 3 alloc'd
==11827==    at 0x4C2615D: malloc (vg_replace_malloc.c:195)
==11827==    by 0x4EAD581: strdup (in /lib64/libc-2.12.90.so)
==11827==    by 0x400525: main (bz626470.c:11)
==11827== 
==11827== Invalid read of size 8
==11827==    at 0x4F6B436: __strcasecmp_l_ssse3 (in /lib64/libc-2.12.90.so)
==11827==    by 0x40054A: main (bz626470.c:13)
==11827==  Address 0x51c9098 is 5 bytes after a block of size 3 alloc'd
==11827==    at 0x4C2615D: malloc (vg_replace_malloc.c:195)
==11827==    by 0x4EAD581: strdup (in /lib64/libc-2.12.90.so)
==11827==    by 0x400533: main (bz626470.c:12)
==11827== 
==11827== 
==11827== HEAP SUMMARY:
==11827==     in use at exit: 6 bytes in 2 blocks
==11827==   total heap usage: 2 allocs, 0 frees, 6 bytes allocated
==11827== 
==11827== LEAK SUMMARY:
==11827==    definitely lost: 6 bytes in 2 blocks
==11827==    indirectly lost: 0 bytes in 0 blocks
==11827==      possibly lost: 0 bytes in 0 blocks
==11827==    still reachable: 0 bytes in 0 blocks
==11827==         suppressed: 0 bytes in 0 blocks
==11827== Rerun with --leak-check=full to see details of leaked memory
==11827== 
==11827== For counts of detected and suppressed errors, rerun with: -v
==11827== ERROR SUMMARY: 4 errors from 4 contexts (suppressed: 6 from 6)
Comment 5 Andreas Schwab 2010-08-24 14:38:46 UTC 
They need to be suppressed in valgrind.
Comment 6 Kamil Dudka 2010-09-07 20:01:44 UTC 
Now the same problem with strncasecmp() - see bug 631449 for details:

 ==20080== Invalid read of size 8
 ==20080==    at 0x5A1117C: __strncasecmp_l_ssse3 (in /lib64/libc-2.12.90.so)
 ==20080==    by 0x505A228: curl_strnequal (in /builddir/build/BUILDROOT/curl-7.21.0-4.fc14.x86_64/usr/lib64/libcurl.so.4.2.0)
 ==20080==    by 0x403625: getparameter (main.c:1958)
 ==20080==    by 0x403376: parseconfig (main.c:3391)
 ==20080==    by 0x403D2D: getparameter (main.c:2803)
 ==20080==    by 0x406F99: main (main.c:4535)
 ==20080==  Address 0x953ae78 is 8 bytes inside a block of size 14 alloc'd
 ==20080==    at 0x4C2615D: malloc (vg_replace_malloc.c:195)
 ==20080==    by 0x594C6A1: strdup (in /lib64/libc-2.12.90.so)
 ==20080==    by 0x403178: parseconfig (main.c:5716)
 ==20080==    by 0x403D2D: getparameter (main.c:2803)
 ==20080==    by 0x406F99: main (main.c:4535)
Comment 7 Andreas Schwab 2010-09-10 11:39:45 UTC 
*** Bug 632555 has been marked as a duplicate of this bug. ***
Comment 8 Jakub Jelinek 2010-11-12 15:53:16 UTC 
Please try valgrind-3.5.0-19.fc14 or valgrind-3.6.0-1.fc15.
Comment 9 Kamil Dudka 2010-11-12 16:36:38 UTC 
Both of them work for me.  Thanks!
Comment 10 Fedora Update System 2010-11-15 11:34:50 UTC 
valgrind-3.5.0-19.fc14 has been submitted as an update for Fedora 14.
https://admin.fedoraproject.org/updates/valgrind-3.5.0-19.fc14
Comment 11 Fedora Update System 2010-11-15 22:22:39 UTC 
valgrind-3.5.0-19.fc14 has been pushed to the Fedora 14 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update valgrind'.  You can provide feedback for this update here: https://admin.fedoraproject.org/updates/valgrind-3.5.0-19.fc14
Comment 12 Fedora Update System 2010-11-17 23:23:02 UTC 
valgrind-3.5.0-19.fc14 has been pushed to the Fedora 14 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 13 Fedora Update System 2010-11-26 14:31:36 UTC 
curl-7.21.0-6.fc14 has been submitted as an update for Fedora 14.
https://admin.fedoraproject.org/updates/curl-7.21.0-6.fc14
Comment 14 Fedora Update System 2010-11-28 20:41:12 UTC 
curl-7.21.0-6.fc14 has been pushed to the Fedora 14 stable repository.  If problems still persist, please make note of it in this bug report.