[Valgrind-users] Probably OT: Losing memory within gethostbyname_r, inet_ntoa

[Andreas O. <oe...@oe...>]

Hello,

sorry if this is a FAQ or just plain stupid, but I didn't find anything
helpful in the docs, FAQ, nor ML/news archives.

While checking my application for memory leaks, I noticed lots of
reports about allocations made from within glibc library calls,
which seem to contradict the documented behaviour of these functions.

For example, gethostbyname_r is not supposed to do any allocations
at all (the result structure and scratch buffer are provided by
the caller). Yet at exit I get lots of these:

==23379== 416 bytes in 3 blocks are still reachable in loss record 10 of 12
==23379==    at 0x40168A63: calloc (vg_clientfuncs.c:245)
==23379==    by 0x4000CAAC: _dl_check_map_versions (in /lib/ld-2.2.4.so)
==23379==    by 0x4035BEAD: dl_open_worker (in /lib/libc.so.6)
==23379==    by 0x4000B59F: _dl_catch_error (in /lib/ld-2.2.4.so)
==23379==    by 0x4035C0AD: _dl_open (in /lib/libc.so.6)
==23379==    by 0x4035CD44: do_dlopen (in /lib/libc.so.6)
==23379==    by 0x4000B59F: _dl_catch_error (in /lib/ld-2.2.4.so)
==23379==    by 0x4035CCDF: dlerror_run (in /lib/libc.so.6)
==23379==    by 0x4035CDE9: __libc_dlopen (in /lib/libc.so.6)
==23379==    by 0x40340AE3: __nss_lookup_function (in /lib/libc.so.6)
==23379==    by 0x40340670: __nss_next (in /lib/libc.so.6)
==23379==    by 0x40343BD3: gethostbyname_r@@GLIBC_2.1.2 (in /lib/libc.so.6)
==23379==    by 0x805F96F: resolve_hostname_to_ip (jbsockets.c:800)
==23379==    by 0x805F269: connect_to (jbsockets.c:296)
==23379==    by 0x805ED73: forwarded_connect (gateway.c:227)
==23379==    by 0x80604C9: chat (jcc.c:1171)
==23379==    by 0x8061491: serve (jcc.c:1692)
==23379==    by 0x4024582B: thread_wrapper (vg_libpthread.c:671)
==23379==    by 0x4016E9DF: (within /usr/local/lib/valgrind/valgrind.so)

Looking closer it seems as if ld was callocing memory for whatever
use, leaving me with a dynamic allocation that I don't have a pointer
to to free it. Even stranger: This being listed under "still reachable"
implies that there is a pointer -- but where?

Also note the oddness of gethostbyname_r@@GLIBC_2.1.2 although the
application and valgrind were compiled and run on a glibc 2.2.4 system.

The other case is about inet_ntoa, which is supposed to reuse the same
statically allocated buffer in subsequent requests. Yet I get multiple
reports like this one:

==23379== 200 bytes in 1 blocks are still reachable in loss record 9 of 12
==23379==    at 0x40244FF4: my_malloc (vg_libpthread.c:267)
==23379==    by 0x40246B41: get_or_allocate_specifics_ptr (vg_libpthread.c:1392)
==23379==    by 0x40246C56: __pthread_key_create (vg_libpthread.c:1429)
==23379==    by 0x40342DF1: init (in /lib/libc.so.6)
==23379==    by 0x40246E7C: __pthread_once (vg_libpthread.c:1514)
==23379==    by 0x40342D18: inet_ntoa (in /lib/libc.so.6)
==23379==    by 0x805F812: accept_connection (jbsockets.c:714)
==23379==    by 0x806204D: listen_loop (jcc.c:2252)
==23379==    by 0x8061D27: main (jcc.c:2072)
==23379==    by 0x402797ED: __libc_start_main (in /lib/libc.so.6)
==23379==    by 0x80496F0: (within /home/oes/projekte/privoxy/current/privoxy)

How and why does __pthread_once get called from within inet_ntoa and what
does valgrind's vg_libpthread need 200 bytes for?

Any hints are greatly appreciated.

Thanks,
--Andreas