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 <stdio.h>
#include <netdb.h>
#include <cstdlib>
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?