Bug#318317: libc6: Numerous (49) memory leaks in gethostbyname, as reported by mudflap

[Florian Weimer <fw@deneb.enyo.de>]

* 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.