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
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 sayin
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 h
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 unti
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 lib
5 matches
Mail list logo
