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