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

[Nicholas N. <nj...@ca...>]

On Thu, 8 May 2003, Andreas Oesterhelt wrote:

> 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?

I don't know why __pthread_once is being called, but its' a leak in
Valgrind's libpthread.so;  mmm, embarassing :(   I committed a suppression
for it in the CVS HEAD this morning (it was very hard to track down so we
settled with suppressing it).

N