Bug 163278 - Numerous (57) memory leaks in gethostbyname, as reported by mudflap
Numerous (57) memory leaks in gethostbyname, as reported by mudflap
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: glibc (Show other bugs)
4
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Jakub Jelinek
Brian Brock
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2005-07-14 14:45 EDT by Vesselin Peev
Modified: 2007-11-30 17:11 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-07-15 04:28:53 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Vesselin Peev 2005-07-14 14:45:51 EDT
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):
glibc-2.3.5-10

How reproducible:
Always

Steps to Reproduce:
1. Create a file main.cpp / main.c with the following contents:

#include <netdb.h>
int main()
{
gethostbyname("www.google.com");
return 0;
}

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

Additional info:

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.
Comment 1 Jakub Jelinek 2005-07-15 04:28:53 EDT
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
internal buffers.
If you use mtrace or valgrind, you'll see that there are no memory leaks
in this case.
Comment 2 Vesselin Peev 2005-07-15 09:17:04 EDT
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 
problem fortunately.

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?

Note You need to log in before you can comment on or make changes to this bug.