Bug 629976

Summary: valgrind claims "Invalid free() ... below main"
Product: [Fedora] Fedora Reporter: Ed Santiago <santiago>
Component: glibcAssignee: Andreas Schwab <schwab>
Status: CLOSED ERRATA QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: low    
Version: 12CC: caolanm, dodji, fweimer, jakub, roland, schwab
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: glibc-2.12.90-14 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2010-09-30 06:15:51 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 reproducer, with instructions. none

Description Ed Santiago 2010-09-03 12:31:48 UTC 
Created attachment 442878 [details]
Minimal reproducer, with instructions.

valgrind, run against a trivial test program linked against libdw, produces what appears to be a false positive:

  ==1575== Memcheck, a memory error detector
  ==1575== Copyright (C) 2002-2009, and GNU GPL'd, by Julian Seward et al.
  ==1575== Using Valgrind-3.5.0 and LibVEX; rerun with -h for copyright info
  ==1575== Command: ./foo
  ==1575== 
  ==1575== Invalid free() / delete / delete[]
  ==1575==    at 0x4A04D72: free (vg_replace_malloc.c:325)
  ==1575==    by 0x350932735A: ??? (in /lib64/libc-2.11.2.so)
  ==1575==    by 0x3509326EF1: ??? (in /lib64/libc-2.11.2.so)
  ==1575==    by 0x480162B: _vgnU_freeres (vg_preloaded.c:62)
  ==1575==    by 0x3509235B31: exit (in /lib64/libc-2.11.2.so)
  ==1575==    by 0x350921EB23: (below main) (in /lib64/libc-2.11.2.so)
  ==1575==  Address 0x4c26508 is not stack'd, malloc'd or (recently) free'd
  ==1575== 
  ==1575== 
  ==1575== HEAP SUMMARY:
  ==1575==     in use at exit: 0 bytes in 0 blocks
  ==1575==   total heap usage: 0 allocs, 1 frees, 0 bytes allocated
  ==1575== 
  ==1575== All heap blocks were freed -- no leaks are possible
  ==1575== 
  ==1575== For counts of detected and suppressed errors, rerun with: -v
  ==1575== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 6 from 6)

See attached foo.c for instructions.  

Note that I only see the failure when linking against libdw.  No other system library causes this behavior.  Roland McGrath believes it to be related to RPATH, and on my Fedora system, libdw is the only library with an RPATH other than /usr/lib64 :

   $ for i in {/usr,}/lib64/lib*.so;do 
        x=$(eu-readelf --all $i 2>/dev/null | grep RPATH);
        if [ -n "$x" ]; then echo $i $x;fi;done

...generates 14 results (including symlink dups), of which 12 are /usr/lib64 and 2 are /usr/lib64/elfutils from libdw.  I am not wise enough to know if this is relevant or a red herring, but this bug report[1] also suggests a connection with RPATH.

  [1] http://sourceware.org/bugzilla/show_bug.cgi?id=10610

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

  valgrind.x86_64        1:3.5.0-14.fc12
  elfutils.x86_64           0.148-1.fc12
Comment 1 Ed Santiago 2010-09-03 20:47:14 UTC 
Update: this is not looking like a problem with valgrind, but I don't know where to refile.  Message thread excerpted & summarized below.

-----------------------------------------------------------------------------

Date: Fri, 3 Sep 2010 14:57:12 +0200
From: Jakub Jelinek <jakub>

I don't think that is valgrind's fault, it looks like a ld.so/libc fault.
If it passes a memory allocated by ld.so's malloc, it shouldn't pass
that ever to free, not even in freeres.
valgrind free isn't the only one that doesn't like that sort of thing,
I bet glibc malloc wouldn't like it too, similarly other malloc
implementations.

------------------------------------------------------------------------------

Date: Fri,  3 Sep 2010 12:51:27 -0700 (PDT)
From: Roland McGrath <roland>

Indeed,

        int main ()
        {
          __libc_freeres ();
          return 0;
        }

compiled with -ldw gets malloc trace crash.

------------------------------------------------------------------------------

Date: Fri,  3 Sep 2010 13:28:47 -0700 (PDT)
From: Roland McGrath <roland>

Any trivial DSO reproduces it if there is both a
DT_RUNPATH and a DT_NEEDED that needs it.

% cat freeres.c
int main ()
{
  __libc_freeres ();
  return 0;
}
% gcc -xc /dev/null -shared -o null.so
% gcc -xc /dev/null -shared -o rpath.so -Wl,null.so -Wl,--enable-new-dtags,-rpat
h,$PWD
% gcc -g -o fmh freeres.c ./rpath.so
% ./fmh
*** glibc detected *** ./fmh: free(): invalid pointer: 0x00007f0f649694d8 ***
Comment 2 Jakub Jelinek 2010-09-08 15:00:26 UTC 
*** Bug 631870 has been marked as a duplicate of this bug. ***
Comment 3 Fedora Update System 2010-09-27 15:48:59 UTC 
glibc-2.12.90-13 has been submitted as an update for Fedora 14.
https://admin.fedoraproject.org/updates/glibc-2.12.90-13
Comment 4 Fedora Update System 2010-09-27 20:07:28 UTC 
glibc-2.12.90-13 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 glibc'.  You can provide feedback for this update here: https://admin.fedoraproject.org/updates/glibc-2.12.90-13
Comment 5 Fedora Update System 2010-09-28 17:32:11 UTC 
glibc-2.12.90-14 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 glibc'.  You can provide feedback for this update here: https://admin.fedoraproject.org/updates/glibc-2.12.90-14
Comment 6 Fedora Update System 2010-09-30 06:15:26 UTC 
glibc-2.12.90-14 has been pushed to the Fedora 14 stable repository.  If problems still persist, please make note of it in this bug report.