[Bug libc/10610] New: valgrind detect 1 extra free() from _vgnU_freeres per shared lib linked

["laurent dot deniau at cern dot ch" <sourceware-bugzilla@sourceware.org>]

See last paragraphs for a quick hint about the bug. Hereafter follow the context where I have (re?) 
discovered the problem. 


Empty program (see below) linked with a shared lib written in standard C89, no _init, _fini or 
__attribute__((constructor)) in the user code so in principle, no user code is executed except the empty 
main.  If main() does something effective (a real program), valgrind report the same errors (and no 
other despite of the real run of the application).

cat main.c
void cos_symbol_init(void);    // required by the user lib
void cos_symbol_init(void) {} // dummy, never called
int main(void) { return 0; } // DO NOTHING!

gcc main.c -o main ./libCosBase_d.so.0.8

ldd ./main
	linux-vdso.so.1 =>  (0x00007fff5abfe000)
	libCosBase_d.so => ./libCosBase_d.so (0x00007fa9526e7000)
	libc.so.6 => /lib/libc.so.6 (0x00007fa952375000)
	libpthread.so.0 => /lib/libpthread.so.0 (0x00007fa952159000)
	libdl.so.2 => /lib/libdl.so.2 (0x00007fa951f55000)
	/lib64/ld-linux-x86-64.so.2 (0x00007fa952924000)

file ./libCosBase_d.so.0.8
./libCosBase_d.so.0.8: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, not 
stripped

 ldd ./libCosBase_d.so
	linux-vdso.so.1 =>  (0x00007fff017ff000)
	libpthread.so.0 => /lib/libpthread.so.0 (0x00007f51f92a2000)
	libdl.so.2 => /lib/libdl.so.2 (0x00007f51f909e000)
	libc.so.6 => /lib/libc.so.6 (0x00007f51f8d2b000)
	/lib64/ld-linux-x86-64.so.2 (0x00007f51f970b000)

valgrind ./main
==2379== Memcheck, a memory error detector.
==2379== Copyright (C) 2002-2008, and GNU GPL'd, by Julian Seward et al.
==2379== Using LibVEX rev 1884, a library for dynamic binary translation.
==2379== Copyright (C) 2004-2008, and GNU GPL'd, by OpenWorks LLP.
==2379== Using valgrind-3.4.1-Debian, a dynamic binary instrumentation framework.
==2379== Copyright (C) 2000-2008, and GNU GPL'd, by Julian Seward et al.
==2379== For more details, rerun with: -v
==2379== 
==2379== Invalid free() / delete / delete[]
==2379==    at 0x4C265AF: free (vg_replace_malloc.c:323)
==2379==    by 0x518D0EA: (within /lib/libc-2.9.so)
==2379==    by 0x518CC81: (within /lib/libc-2.9.so)
==2379==    by 0x4A215A0: _vgnU_freeres (vg_preloaded.c:60)
==2379==    by 0x509F764: exit (in /lib/libc-2.9.so)
==2379==    by 0x50875AC: (below main) (in /lib/libc-2.9.so)
==2379==  Address 0x4030000 is not stack'd, malloc'd or (recently) free'd
==2379== 
==2379== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 8 from 1)
==2379== malloc/free: in use at exit: 0 bytes in 0 blocks.
==2379== malloc/free: 0 allocs, 1 frees, 0 bytes allocated.
==2379== For counts of detected errors, rerun with: -v
==2379== All heap blocks were freed -- no leaks are possible.

Looks like  _vgnU_freeres call free() with an address of a function or a (shared?) data segment (address 
0x4030000).

Adding another shared lib to the link add an extra invalid free

gcc main.c -o main ./libCosBase_d.so.0.8 ./libCosStd_d.so.0.1

ldd ./main
	linux-vdso.so.1 =>  (0x00007fffacffe000)
	libCosStd_d.so => ./libCosStd_d.so (0x00007f58a4835000)
	libc.so.6 => /lib/libc.so.6 (0x00007f58a44c3000)
	libCosBase_d.so => ./libCosBase_d.so (0x00007f58a4286000)
	libm.so.6 => /lib/libm.so.6 (0x00007f58a4001000)
	/lib64/ld-linux-x86-64.so.2 (0x00007f58a4c40000)
	libpthread.so.0 => /lib/libpthread.so.0 (0x00007f58a3de5000)
	libdl.so.2 => /lib/libdl.so.2 (0x00007f58a3be1000)

file ./libCosStd_d.so.0.1
./libCosStd_d.so.0.1: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, not 
stripped

ldd ./libCosStd_d.so
	linux-vdso.so.1 =>  (0x00007fffb49fe000)
	libCosBase_d.so => ./libCosBase_d.so (0x00007f5cac201000)
	libm.so.6 => /lib/libm.so.6 (0x00007f5cabf6f000)
	libc.so.6 => /lib/libc.so.6 (0x00007f5cabbfc000)
	/lib64/ld-linux-x86-64.so.2 (0x00007f5cac84c000)
	libpthread.so.0 => /lib/libpthread.so.0 (0x00007f5cab9e0000)
	libdl.so.2 => /lib/libdl.so.2 (0x00007f5cab7dc000)

valgrind ./main
==2671== Memcheck, a memory error detector.
==2671== Copyright (C) 2002-2008, and GNU GPL'd, by Julian Seward et al.
==2671== Using LibVEX rev 1884, a library for dynamic binary translation.
==2671== Copyright (C) 2004-2008, and GNU GPL'd, by OpenWorks LLP.
==2671== Using valgrind-3.4.1-Debian, a dynamic binary instrumentation framework.
==2671== Copyright (C) 2000-2008, and GNU GPL'd, by Julian Seward et al.
==2671== For more details, rerun with: -v
==2671== 
==2671== Invalid free() / delete / delete[]
==2671==    at 0x4C265AF: free (vg_replace_malloc.c:323)
==2671==    by 0x535B0EA: (within /lib/libc-2.9.so)
==2671==    by 0x535AC81: (within /lib/libc-2.9.so)
==2671==    by 0x4A215A0: _vgnU_freeres (vg_preloaded.c:60)
==2671==    by 0x526D764: exit (in /lib/libc-2.9.so)
==2671==    by 0x52555AC: (below main) (in /lib/libc-2.9.so)
==2671==  Address 0x4030060 is not stack'd, malloc'd or (recently) free'd
==2671== 
==2671== ERROR SUMMARY: 2 errors from 1 contexts (suppressed: 8 from 1)
==2671== malloc/free: in use at exit: 0 bytes in 0 blocks.
==2671== malloc/free: 0 allocs, 2 frees, 0 bytes allocated.
==2671== For counts of detected errors, rerun with: -v
==2671== All heap blocks were freed -- no leaks are possible.

Linking statically the libraries (one or two) does not show any problem. Removing -rpath linking option 
during the built of the libraries also remove the problem. So the cleaning problem in _vgnU_freeres() 
should be related to unloading shared libraries built with the -rpath option passed to the linker.

This bug seems to be known for more than a year
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=456303
but I am not sure if it's the same and I haven't found any reference to it in the glibc bug db.

Feel free to ask more details.

Best Regards,

Laurent.

-- 
           Summary: valgrind detect 1 extra free() from _vgnU_freeres per
                    shared lib linked
           Product: glibc
           Version: 2.9
            Status: NEW
          Severity: normal
          Priority: P2
         Component: libc
        AssignedTo: drepper at redhat dot com
        ReportedBy: laurent dot deniau at cern dot ch
                CC: glibc-bugs at sources dot redhat dot com
 GCC build triplet:  gcc -v Using built-in specs. Target: x86_64-linux-gnu
                    Configure
  GCC host triplet: Linux ubuntu 2.6.28-15-generic #49-Ubuntu SMP Tue Aug 18
                    19:25:3
GCC target triplet: idem


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

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.