Red Hat Bugzilla – Bug 163278
Numerous (57) memory leaks in gethostbyname, as reported by mudflap
Last modified: 2007-11-30 17:11:10 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.8) Gecko/20050513 Fedora/1.0.4-1.3.1 Firefox/1.0.4
Description of problem:
Just calling gethostbyname in a program and running it with mudflap on reports 57 memory leaks. The number of leaks reported in Fedora Core 3, the previous version, is 58, one more ;).
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Create a file main.cpp / main.c with the following contents:
2. Then execute the following:
g++ -fmudflap (the filename you created above) -lmudflap
That will of course create an executable named a.out in the current directory.
3. Before running, execute the following:
export MUDFLAP_OPTIONS='-internal-checking -print-leaks -check-initialization'
4. Finally, execute a.out.
Actual Results: A barrage of memory leak information reports is printed to the console, by mudflap, finishing with the line:
number of leaked objects: 57
Expected Results: No memory leak information should have been reported, and the final printed line should have been:
number of leaked objects: 0
I have tested with a fully updated Debian Sarge i386, unstable branch. The leaks reported with it are less, but still too many. They are 49.
You are using a wrong tool for that.
glibc doesn't free memory unnecessarily on program exit, only when using
memory leak checking tools like mtrace or valgrind it will free all its
If you use mtrace or valgrind, you'll see that there are no memory leaks
in this case.
I have been using valgrind on that, and actually valgrind in Fedora Core 3
currently produces errors on the same snippet -- "Conditional jump or move
depends on uninitialised value(s)". But Fedora Core 4 doesn't have this
Do you think that mudflap will eventually have the support for that, because
after all mudflap comes with the compiler, and has an option -print-leaks?
There are also other problems I could report, but I am not sure if I should do
it. Mudflap reports a lot of errors in a multithreaded program with pthreads --
and not only leaks. Perhaps I should report the non-leak related
multithreading errors only, as a gcc bug?