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
* 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
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,
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
* 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
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
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
* 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
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
9 matches
Mail list logo
