Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 163278 - Numerous (57) memory leaks in gethostbyname, as reported by mudflap
Summary: Numerous (57) memory leaks in gethostbyname, as reported by mudflap
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Fedora
Classification: Fedora
Component: glibc
Version: 4
Hardware: i386
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Jakub Jelinek
QA Contact: Brian Brock
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2005-07-14 18:45 UTC by Vesselin Peev
Modified: 2007-11-30 22:11 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2005-07-15 08:28:53 UTC


Attachments (Terms of Use)

Description Vesselin Peev 2005-07-14 18:45:51 UTC
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 08:28:53 UTC
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 13:17:04 UTC
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.