home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #27 / NN_1992_27.iso / spool / comp / lang / c / 16795 < prev    next >
Encoding:
Text File  |  1992-11-19  |  1.6 KB  |  37 lines
  1. Newsgroups: comp.lang.c
  2. Path: sparky!uunet!inmos!titan.inmos.co.uk!news
  3. From: conor@lion.inmos.co.uk (Conor O'Neill)
  4. Subject: Re: Help me track down memory leakage
  5. Message-ID: <1992Nov19.161411.25199@titan.inmos.co.uk>
  6. Sender: news@titan.inmos.co.uk
  7. Reply-To: conor@inmos.co.uk (Conor O'Neill)
  8. Organization: INMOS Limited, Bristol, UK.
  9. References: <BxuLIr.DK@rice.edu>
  10. Date: Thu, 19 Nov 1992 16:14:11 GMT
  11. Lines: 24
  12.  
  13. In article <BxuLIr.DK@rice.edu> abuhr@owlnet.rice.edu (Aaron M. Buhr) writes:
  14. >     I've inherited a very large C program that I am trying to maintain and
  15. >expand, and I've come to the point where I HAVE to find out where the
  16. >program's leaking memory.  The program starts out with about 7MB virtual
  17. >mem usage, 6MB real, and grows over the course of 6-8 hours to around 20MB
  18. >virtual, 10MB real.  The program uses straight malloc() and realloc() calls.
  19. >I don't know where or how to start trying to track this down.  Any help
  20. >would be greatly appreciated.  Email is preferred, but I'll try to watch
  21. >the posts to this group as well.  Much thanks in advance.
  22.  
  23. The 'purify' system, which I used on a Sun 4, seems very good.
  24.  
  25. It is very easy to use - you just edit your 'link' line in your makefile.
  26. It reports stuff such as some illegal pointer accesses, eg accesses
  27. to free-d memory, and also gives a list of all memory which is still
  28. allocated at program termination, and tells you where it was malloc-ed.
  29.  
  30.  
  31.  
  32.  
  33. ---
  34. Conor O'Neill, Software Group, INMOS Ltd., UK.
  35. UK: conor@inmos.co.uk        US: conor@inmos.com
  36. "It's state-of-the-art" "But it doesn't work!" "That is the state-of-the-art".
  37.