We help IT Professionals succeed at work.

How can I track down a memory leak?

klopter asked
Last Modified: 2013-12-14
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.
Watch Question

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. http://www.rational.com/products/purify_nt/tryit/index.jtmpl  It would gove you 14 days to work with it.

Does it work with gcc?

Hmmm, good point.  I'm not sure.
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).

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.
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.  
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.)
This one is on us!
(Get your first solution completely free - no credit card required)


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_.
Unlock the solution to this question.
Join our community and discover your potential

Experts Exchange is the only place where you can interact directly with leading experts in the technology field. Become a member today and access the collective knowledge of thousands of technology experts.

*This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.


Please enter a first name

Please enter a last name

8+ characters (letters, numbers, and a symbol)

By clicking, you agree to the Terms of Use and Privacy Policy.