Libc6 2.0.5c has a leak in inet_ntoa (fwd)

["Roberto A. Lumbreras Pastor" <rover@lander.es>]

Hi all.

Sorry if you already have this message, but I think it is
important.

It seems that there is a memory leak in libc-2.0.5c.

Well, now I know why the squid I'm testing in my alpha box has to
been killed too often, and it really is doing nothing :)

What are the plans with libc6? We are going to have a libc-2.0.6?

Regards,
-- 
Roberto Lumbreras Pastor  *  mailto:rover@lander.es
Lander Internet - Spain   *  http://www.lander.es/
Tel +34 1 556.28.83       *  Fax +34 1 556.30.01

"Encryption renamed to Encode to avoid US regulation problems"
                     - include/linux/wireless.h in Linux 2.0.30 kernel

---------- Forwarded message ----------
From: Philippe Troin <phil@fifi.org>
To: debian-devel@lists.debian.org
Date: Wed, 26 Nov 1997 03:38:39 +0800
Subject: Libc6 2.0.5c has a leak in inet_ntoa


I should have sent this email much earlier since I've found this 
problem more than a week ago:
Libc6 2.0.5c has a leak in inet_ntoa.
This simple program will prove it:

        #include <sys/socket.h>
        #include <netinet/in.h>
        #include <arpa/inet.h>

        void main(void) {
            char *a;
            struct in_addr s;
            while(1) {
                a=inet_ntoa(s);
            }
        }

Run it and watch it grow.
This explains the diald 0.16.4-10 memory leak (and might explain the 
nfsd leak too).

The inside story is: due to a problem with libc6, libc_create_key is 
not declared as a weak symbol of libpthread, and it's not wrapped in 
a macro which detects if the program is linked with libpthread.
The result is that during the first call to inet_ntoa(), a libc_once 
initialization routine is called, it thinks it's linked with 
libpthread and attempts to create a thread-specific return buffer 
through libc_create_key. It  believes that the call completed 
successfully. It does not setup a process-wide buffer.
For each invocation of inet_ntoa, libc_get_key returns null, and 
inet_ntoa thinks it's the first time it's been called and mallocs() a 
buffer. It normally stores it with libc_set_key, but it fails (and 
this is not reported).
Every time the function is called, 16 bytes are lost.

The normal operation would be:
1) Libpthread is not present.
   The libc_once initialization routine detects that libc_create_key 
   isn't there and sets up a global buffer. Inet_ntoa uses this 
buffer.
2) Libpthread is present.
   The libc_once initialization routine creates thread-specific keys.
   During the first invocation of inet_ntoa in each thread,
   the thread-specific key is accessed. If null, a buffer is allocated
   with malloc, once per thread, and is stored for future use.

This is what libc6 2.0.6 does (I've checked).

In the meantime, you can link programs which do heavy inet_ntoa with 
libpthread, it will cure the leak (diald 0.16.4-11 does this, as a 
temporary measure while waiting for libc6 2.0.6).

I hope this is not too confusing :-)

Phil.


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
debian-devel-request@lists.debian.org . 
Trouble?  e-mail to templin@bucknell.edu .



--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
debian-alpha-request@lists.debian.org . 
Trouble?  e-mail to templin@bucknell.edu .