Bug#318317: libc6: Numerous (49) memory leaks in gethostbyname, as reported by mudflap
Very simple: gethostbyname() returns a struct hostent * for which the
C library has to allocate some internal memory. However,
POSIX/SUS/etc. does not define any API to tell the C library that the
returned pointer is no longer needed, so the allocated memory cannot be
freed by the C library until the next call to gethostbyname().
Solution: do not use the gethostby* functions. Use get{addr|name}info()
instead, they do not have this API problem (and have other advantages
as well).
Florian and Gabor -- thanks! Gabor, I am using gethostbyname for portability
reasons, since some systems may lack the other APIs, but it indeed would be
good then to add a code path that uses the abovementioned functions, which I
recently became aware of myself.
Finally -- when the program is:
#include stdlib.h
#include netdb.h
int main()
{
stuct hostent* hi = gethostbyname(www.google.com);
free(hi);
return 0;
}
the number of leaks reported does not change (nor other errors appear) so it
seems that it is not the hostent structure that causes this, but rather some
other state that gethostbyname keeps. Note that mudflap prints the leak
report at program termination.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#318317: libc6: Numerous (49) memory leaks in gethostbyname, as reported by mudflap
* Vesselin Peev:
This is not a problem, unless this number grows with each
gethostbyname invocation. The underlying programming pattern which
causes this is quite common and perfectly harmless (if you get the
threading issues right, of coruse).
Just tested it in a loop, the leaks stay constant.
Fine, thanks.
If you are saying the underlying programming pattern is quite common
and harmless, that does not also mean that the leaks are
non-existent and mudflap is confused, right?
Yes. AFAIK, mudflap does not perform pointer tracing (unlike
valgrind). Therefore, it cannot detect if heap objects which are
allocated when the program terminates are still reachable, which is
the case here.
Could you please elucidate what is this programming pattern that
causes the leaks, if it is possible to do with a programming
snippet?
A variable at global scope which points to an object allocated on the
heap, for example:
static char *name = NULL;
void
set_name (char *n)
{
free (name);
name = strdup (n);
}
There's no need to free name at program termination because the kernel
will do it for you anyway.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#318317: libc6: Numerous (49) memory leaks in gethostbyname, as reported by mudflap
On Fri, Jul 15, 2005 at 05:10:09PM +0300, Vesselin Peev wrote: I know the problem is not present with valgrind on Debian, too, so the above then holds for the Debian libc package, too. From his words one can conclude that there must be a better integration between mudflap and glibc. Well, I know nothing about mudflap, but valgrind calls __libc_freeres() at program termination to avoid internal data allocated by glibc being reported as leaks. Gabor -- - MTA SZTAKI Computer and Automation Research Institute Hungarian Academy of Sciences, Laboratory of Parallel and Distributed Systems Address : H-1132 Budapest Victor Hugo u. 18-22. Hungary Phone/Fax : +36 1 329-78-64 (secretary) W3: http://www.lpds.sztaki.hu - -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#318317: libc6: Numerous (49) memory leaks in gethostbyname, as reported by mudflap
On Thu, Jul 14, 2005 at 10:17:32PM +0300, Vesselin Peev wrote:
Could you please elucidate what is this programming pattern that causes the
leaks, if it is possible to do with a programming snippet? I find it very
strange that a well-working program will have leaks that are considered
necessary because of a quite common usage pattern. Isn't there a better,
more perfect way?
Very simple: gethostbyname() returns a struct hostent * for which the
C library has to allocate some internal memory. However,
POSIX/SUS/etc. does not define any API to tell the C library that the
returned pointer is no longer needed, so the allocated memory cannot be
freed by the C library until the next call to gethostbyname().
Solution: do not use the gethostby* functions. Use get{addr|name}info()
instead, they do not have this API problem (and have other advantages
as well).
Gabor
--
-
MTA SZTAKI Computer and Automation Research Institute
Hungarian Academy of Sciences
-
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#318317: libc6: Numerous (49) memory leaks in gethostbyname, as reported by mudflap
* Vesselin Peev: I'm thinking of submitting a wish about better handling, You could reuse this bug report (downgrade it to wishlist, reassign if necessary). if possible with the mudflap architecture, of internal data allocated by libc. Proper handling should of course include no unaccessed registered object warnings. Barring that, I'd request a mudflap option to suppress those warnings. What would you advise me? Mudflap needs some GNU libc interface to do this. __libc_freeres looks very internal. It's not documented, either. I believe it can go away in the next release. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#318317: libc6: Numerous (49) memory leaks in gethostbyname, as reported by mudflap
Well, I know nothing about mudflap, but valgrind calls __libc_freeres()
at program termination to avoid internal data allocated by glibc being
reported as leaks.
Thanks for mentioning this, Gabor! I searched for more info about it, and
found it mentioned in the Valgrind FAQ, and also in the libstdc++
documentation. The latter says thankfully mentions how to use
__libc_freeres. Here's a possible revised version of the gethostbyname
snippet:
#include stdio.h
#include netdb.h
#include cstdlib
extern C void __libc_freeres();
int main()
{
atexit(__libc_freeres);
gethostbyname(www.google.com);
char *s = new char[100];
return 0;
}
After compiling it with mudflap on and the -print-leaks options on as well,
I got:
1 memory leak -- the one I deliberately introduced in the code!
The other, the erroneously reported ones, were gone for good!
However, there were many mudflap warning: unaccessed registered object
reports. Yet it seems they are benign -- registered object here means object
that is registered by mudflap itself. I cannot find a way to suppress those
warnings (no option in mudflap) but they all go away when I do not use
the -print-leaks option.
But still this is significant progress for my needs, since mudflap now shows
only *real* memory leaks! This is indeed much better!
I'm thinking of submitting a wish about better handling, if possible with
the mudflap architecture, of internal data allocated by libc. Proper
handling should of course include no unaccessed registered object
warnings. Barring that, I'd request a mudflap option to suppress those
warnings. What would you advise me?
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#318317: libc6: Numerous (49) memory leaks in gethostbyname, as reported by mudflap
Package: libc6
Version: 2.3.2.ds1-22
Severity: normal
How to reproduce:
Create a file main.cpp / main.c with the following contents:
#include netdb.h
int main()
{
gethostbyname(www.google.com);
return 0;
}
Then execute the following:
g++-4.0 -fmudflap (the filename you created above) -lmudflap
That will of course create an executable named a.out in the current directory.
Before running, execute the following:
export MUDFLAP_OPTIONS='-internal-checking -print-leaks
-check-initialization'
Finally, execute a.out.
Note the barrage of memory leak information reports printed to the console,
finishing with the line:
number of leaked objects: 49
-- System Information:
Debian Release: testing/unstable
APT prefers unstable
APT policy: (500, 'unstable'), (500, 'stable')
Architecture: i386 (i686)
Shell: /bin/sh linked to /bin/bash
Kernel: Linux 2.6.8-2-386
Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1)
Versions of packages libc6 depends on:
ii libdb1-compat 2.1.3-7The Berkeley database routines [gl
libc6 recommends no packages.
-- no debconf information
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#318317: libc6: Numerous (49) memory leaks in gethostbyname, as reported by mudflap
* Vesselin Peev:
#include netdb.h
int main()
{
gethostbyname(www.google.com);
return 0;
}
number of leaked objects: 49
This is not a problem, unless this number grows with each
gethostbyname invocation. The underlying programming pattern which
causes this is quite common and perfectly harmless (if you get the
threading issues right, of coruse).
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#318317: libc6: Numerous (49) memory leaks in gethostbyname, as reported by mudflap
This is not a problem, unless this number grows with each gethostbyname invocation. The underlying programming pattern which causes this is quite common and perfectly harmless (if you get the threading issues right, of coruse). Just tested it in a loop, the leaks stay constant. If you are saying the underlying programming pattern is quite common and harmless, that does not also mean that the leaks are non-existent and mudflap is confused, right? If the leaks do not exist, I'd file a report for mudflap, but I get they do exist, and despite harmless, then this is still a problem with something and not a serious one -- that is why I have filed it as normal, and not serious. I have also filed an identical bug report for Fedora Core 4, where the leaks reported are 57. Could you please elucidate what is this programming pattern that causes the leaks, if it is possible to do with a programming snippet? I find it very strange that a well-working program will have leaks that are considered necessary because of a quite common usage pattern. Isn't there a better, more perfect way? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
