How can I track down a memory leak?

I have reason to believe that the code that
I am dealing with has a memory leak in
it, on the system that I am using (a fairly old
gcc compiler/library).

How can I track this down?

P.S.  Many of you will undoubtably advise me
to switch to a newer compiler.  I know that I
should but I have reasons for not doing so
at this point.
Who is Participating?

Improve company productivity with a Business Account.Sign Up

ntdragonConnect With a Mentor Commented:
if you use class's then just
add a static data member num and
in the c'tor do num++
and in the d'tor do num--;

if you have questions about how to make this static data member send me an e-mail.
Answer:  switch to a new compiler.


One way would be to overload new and delete to record each allocation in a table along with the line number and file name of each allocation and remove these entries on each deletion.  (This is someting that modern compilers can often do for you...)  This is quite a bit of work though.  (Well, not that bad, but it isn't a quick fix.)
Download a trial version of Purify.  It would gove you 14 days to work with it.
Free Tool: ZipGrep

ZipGrep is a utility that can list and search zip (.war, .ear, .jar, etc) archives for text patterns, without the need to extract the archive's contents.

One of a set of tools we're offering as a way to say thank you for being a part of the community.

Does it work with gcc?
Hmmm, good point.  I'm not sure.
nils pipenbrinckCommented:
I usually do this with some lines of assembler code.. that's a little bit tricky, but gives GREAT results.

I simply write a new malloc and free routine which takes the same parameters as the old malloc & free.

then I change the names of malloc and free in the library using a hex-editor.. someting like mallox and frex usually work.

in my new malloc I call mallox to get the memory with some extra bytes.

in these bytes I store a linked list of all allocated objects along with the caller address (I get these directly from the stack using some asm lines and a little bit try % error).

in my free I first remove the  memory-block from my linked list (a nice spot to find out if a memory block has been freed twice btw).

at the end of the program you can walk down the linked list and print out the size and caller address of all non-freed memory blocks.

take your map-file and you'll find exactly in which lines/routines the memory wasn't freed.

it may take a day or two to get this working, but after you did it you have one of the best heap debugging systems you can have...

I do this with watcom c++ under dos & windows, but it works with any compiler.

happy coding,

  save the whales!
  feed the hungry!
  free the mallocs!
I think if you try what I suggest,  you would it easier and portable and you don't have to use a map file (which can be a bit tough when you have an application that is upwards of a few 100K).
nils pipenbrinckCommented:

that would work.. agreed.

but it won't track errors in the stdlib (which still use malloc and free), and won't also work for third party libraries.


>>  track errors in the stdlib (which still use
>> malloc and free), and won't also work
>> for third party libraries.
True but in my experience all bugs are caused by only one programmer--me.  I don't know if that is your experience or not.  (If it is, you must really hate me. :-)   )

actuallly this approach will work to track errors in the STL lib too, just not in the compiled library code.
nils pipenbrinckCommented:
well, I guess it's fair when I withdraw my answer. maybe it's to harcore for the average programmer.

nietod: I agree, the stl is mostly bugfree. I work most of the time with watcom C, the stl has memory leaks, but I can live with them (below 1 k total.. mostly i/o buffers). However, I do programming on game consoles, and we have to use third party libraries and libs, that are made that fast, that they haven't been really tested. you won't beleave what shitty code you have to deal with (memory leaks included).

>>  harcore for the average programmer.
I was a full-time assembly language programmer for 10+ years and still do a few hours of assembly every week.  (currently full time again) and I find it too hardore.  But as you said it does have an advantage or two that my approach does not.  
nils pipenbrinckCommented:
you do assembly programming? nietod, you answer to almost any question I ask.. could you please tell me where do you get the time to do so? :)

Assembler is my favorite language.. from time to time I also can use it at work, but most of the stuff I do is just for home use..

ehm.. I'm gettig quite offtopic.. better I'll stop now.

answer: I don't do anything else.  

(I check out EE while I'm waiting for compiles/asembles/tests etc to finish.)
klopterAuthor Commented:
I am sorry.  I don't know what c'tor
or d'tor means.


nils, I am comfortable with assembly,
I even comtemplated your solution,
but I was hoping for a simpler solution.
"c'tor" is "constructor and (need I say it?) "d'tor" is "destructor"

He is proposing adding static data members to each class that counts the number of instances of each class.  When the program ends the number of instances should be 0.  The problem with this is that a) it won't detect non-object based based memory leaks (which may not be a problem and b) it is hard to learn the value of these counters at program termination--this is a problem.  I have fooled with solutions to the second part and never really came up with an answer i really liked.  Although for me alot of the problem had to do with DLLs.  Do you have DLLs?

The solution I proposed will be simpler than nil's but provides slightly less coverage (which is now annoying me because I begin to wonder about my program...).  it is completely standard C++ so there is no assembly or portability problems, however it still is not _simple_.
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.