Bug#272219: Valgrind bug probably due to libc6
Valgrind problem on most recent Sarge (18 Sep 2004).
I'm not completely sure whether the bug is due to libc6,
but that's my best guess.
A rather large program of mine, when compiled and run with
valgrind on the latest sarge, gets a SIGSEGV signal:
$ valgrind ./eisclient
==2714== Memcheck, a memory error detector for x86-linux.
==2714== Copyright (C) 2002-2004, and GNU GPL'd, by Julian Seward et al.
==2714== Using valgrind-2.2.0, a program supervision framework for x86-linux.
==2714== Copyright (C) 2000-2004, and GNU GPL'd, by Julian Seward et al.
==2714== For more details, rerun with: -v
==2714== Process terminating with default action of signal 11 (SIGSEGV): dumping core
==2714== at 0x1B8EA23C: _dl_map_object (in /lib/ld-2.3.2.so)
==2714== by 0x1B8EEA18: (within /lib/ld-2.3.2.so)
==2714== by 0x1B8EFF25: _dl_catch_error (in /lib/ld-2.3.2.so)
==2714== by 0x1B8EF490: _dl_map_object_deps (in /lib/ld-2.3.2.so)
==2714== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
==2714== malloc/free: in use at exit: 0 bytes in 0 blocks.
==2714== malloc/free: 0 allocs, 0 frees, 0 bytes allocated.
==2714== For a detailed leak analysis, rerun with: --leak-check=yes
==2714== For counts of detected errors, rerun with: -v
$ ldd eisclient
libstdc++.so.5 => /usr/lib/libstdc++.so.5 (0x40026000)
libm.so.6 => /lib/libm.so.6 (0x400e0000)
libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x40102000)
libc.so.6 => /lib/libc.so.6 (0x4010c000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
The same binary runs fine with valgrind on a slightly older Sarge,
without the SIGSEGV. With the same /usr/bin/valgrind.bin, the only
apparent difference is in the libc packages:
2.3.2.ds1-16 triggers the bug, 2.3.2.ds1-13 doesn't.
I found a small program to trigger the same bug on the Internet:
int main( int argc, char* argv )
handle = dlopen( argv, RTLD_LAZY );
dlclose( handle );
Compile with g++ -o main main.c -ldl, then run with valgrind.
The error messages are identical to above, even the addresses
reported by valgrind are the same.
I have put my binary of this small program on a website
http://www.clausfischer.com/valgrind-bug in order to exclude
influence of different compilers.
The problem exists both with valgrind versions 2.1.2-2 and
Claus Fischer <email@example.com>