Bug in libc?
I ran the following piece of code through valgrind 3.0.0 on my
Debian/testing pure amd64:
#include <netdb.h>
int main(int argc, char** argv)
{
struct hostent* hp;
char* hostn = "diesel";
hp = gethostbyname(hostn);
return 0;
}
When I compile and link the code with gcc-3.3 and run it with valgrind
I'm getting:
==4919== Invalid read of size 8
==4919== at 0x1190F8D4: (within /lib/ld-2.3.2.so)
==4919== by 0x1190857F: (within /lib/ld-2.3.2.so)
==4919== by 0x11904EBC: (within /lib/ld-2.3.2.so)
==4919== by 0x1190400A: _dl_map_object (in /lib/ld-2.3.2.so)
==4919== by 0x11D1D56B: (within /lib/libc-2.3.2.so)
==4919== by 0x1190AC4F: _dl_catch_error (in /lib/ld-2.3.2.so)
==4919== by 0x11D1D3EE: _dl_open (in /lib/libc-2.3.2.so)
==4919== by 0x11D1F040: (within /lib/libc-2.3.2.so)
==4919== by 0x1190AC4F: _dl_catch_error (in /lib/ld-2.3.2.so)
==4919== by 0x11D1EEFA: __libc_dlopen_mode (in /lib/libc-2.3.2.so)
==4919== by 0x11CFF8D2: __nss_lookup_function (in /lib/libc-2.3.2.so)
==4919== by 0x11CFF482: (within /lib/libc-2.3.2.so)
==4919== Address 0x11F63408 is 16 bytes inside a block of size 23 alloc'd
==4919== at 0x11B1AEFB: malloc (vg_replace_malloc.c:149)
==4919== by 0x11905FAC: (within /lib/ld-2.3.2.so)
==4919== by 0x11904249: _dl_map_object (in /lib/ld-2.3.2.so)
==4919== by 0x11D1D56B: (within /lib/libc-2.3.2.so)
==4919== by 0x1190AC4F: _dl_catch_error (in /lib/ld-2.3.2.so)
==4919== by 0x11D1D3EE: _dl_open (in /lib/libc-2.3.2.so)
==4919== by 0x11D1F040: (within /lib/libc-2.3.2.so)
==4919== by 0x1190AC4F: _dl_catch_error (in /lib/ld-2.3.2.so)
==4919== by 0x11D1EEFA: __libc_dlopen_mode (in /lib/libc-2.3.2.so)
==4919== by 0x11CFF8D2: __nss_lookup_function (in /lib/libc-2.3.2.so)
==4919== by 0x11CFF482: (within /lib/libc-2.3.2.so)
==4919== by 0x11D01163: __nss_hosts_lookup (in /lib/libc-2.3.2.so)
Looks like a bug in libc6 (2.3.2.ds1-22). Before I file a bug report I
thought I'd see what you folks thought. Everything is so new on this
system (debian/testing amd64, valgrind 3.0.0, etc.) I don't want to
ring a false alarm.
Thanks,
Gary
Reply to: