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.