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
#include
#include
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
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
#include
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
Jakub Jelinek from Red Hat said the following: "glibc doesn't free memory unnecessarily on program exit, only when using memory leak checking tools like mtrace or valgrind it will free all its internal buffers." 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. -- 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]
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
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]
