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
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 ***
*** Bug 631870 has been marked as a duplicate of this bug. ***
glibc-2.12.90-13 has been submitted as an update for Fedora 14. https://admin.fedoraproject.org/updates/glibc-2.12.90-13
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
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
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.