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?
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]