NetNews Usenet Archive 1992 #27/NN_1992_27.iso/spool/comp/lang/c/16690

Internet Message Format | 1992-11-17 | 1.7 KB

Path: sparky!uunet!ukma!cs.widener.edu!dsinc!netnews.upenn.edu!netnews.cc.lehigh.edu!ns1.cc.lehigh.edu!dsbb
From: [e-mail] (D. SPENCER BEECHER)
Newsgroups: comp.lang.c
Subject: Re: Help me track down memory leakage
Message-ID: <[e-mail]>
Date: 17 Nov 92 17:05:30 GMT
Organization: Lehigh University
Lines: 25

In article <[e-mail]>, [e-mail] (Aaron M. Buhr) writes:
>
>     I've inherited a very large C program that I am trying to maintain and
>expand, and I've come to the point where I HAVE to find out where the
>program's leaking memory.  The program starts out with about 7MB virtual
>mem usage, 6MB real, and grows over the course of 6-8 hours to around 20MB
>virtual, 10MB real.  The program uses straight malloc() and realloc() calls.
>I don't know where or how to start trying to track this down.  Any help
>would be greatly appreciated.

Try investigating "free()".  Do a (word processing) search on the string
"alloc", trace the associated variable use, and free those pointers that
become obsolete.  Do them one at a time if you're unsure about their
individual obsolescence.  A decent compiler should give you a warning if
memory for a necessary variable has been deallocated.  Make sure the
switch for checking this type of thing is on in your compiler.  I imagine
most of the memory suck can be attributed to structure or array allocation.
The first pointers I would check are those which are not used as parameters
by any function.
A word processor with a "search" function, a hard copy, and several colored
markers would probably be invaluable tools.
--
                   _ _     _ _     _ _
  -Spence         [O.O]   )x.x(   )O.O(
                    O       O      -*-