home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #27 / NN_1992_27.iso / spool / comp / lang / c / 17090 < prev    next >
Encoding:
Text File  |  1992-11-24  |  3.5 KB  |  83 lines
  1. Newsgroups: comp.lang.c
  2. Path: sparky!uunet!munnari.oz.au!cs.mu.OZ.AU!munta.cs.mu.OZ.AU!fjh
  3. From: fjh@munta.cs.mu.OZ.AU (Fergus James HENDERSON)
  4. Subject: Re: Help me track down memory leakage
  5. Message-ID: <9232915.10284@mulga.cs.mu.OZ.AU>
  6. Sender: news@cs.mu.OZ.AU
  7. Organization: Computer Science, University of Melbourne, Australia
  8. References: <BxuLIr.DK@rice.edu> <1992Nov19.161411.25199@titan.inmos.co.uk> <By6G98.68L@rice.edu>
  9. Date: Tue, 24 Nov 1992 04:58:23 GMT
  10. Lines: 71
  11.  
  12. abuhr@owlnet.rice.edu (Aaron M. Buhr) writes:
  13.  
  14. >      Thanks to all who responded to my earlier post about helping me
  15. >track down the memory leak.  Most of the respondents said to either
  16. >acquire a commercial product such as Purify, use one of the freely
  17. >available routines, or make my own.  Since the Purify product is
  18. >priced in the thousands of dollars it's out of my price range.  The
  19. >only standard free memory allocation debugging product seemed to be
  20. >the malloc_debug routines available on some Suns.  I decided to make
  21. >my own routines, both so that I could customize it to fit my uses and
  22. >because I thought I might be able to create my own faster than I could
  23. >track down, learn, and integrate someone else's routine.
  24.  
  25. There is a package called dbmalloc which is free software, and comes
  26. with source code and good documentation. I have found it to be very
  27. easy to install and to use. I doubt that you would need to customize
  28. it, but if you do, the source code is meticulously documented so it
  29. shouldn't be too difficult. My only gripe is that it won't give you a
  30. full stack trace (can't expect too much for $0 I guess :-), but it does
  31. provide some hooks to work around that in particular cases.
  32.  
  33. Here's some extracts from the man page:
  34.  
  35.      DEBUG_MALLOC(3)        UNIX System    V (VTI)           DEBUG_MALLOC(3)
  36.  
  37.      NAME
  38.       dbmalloc - debugging malloc library
  39.  
  40.      [...]
  41.      DESCRIPTION
  42.       This malloc library is a replacement for the standard
  43.       library to be    used during software development/debugging.
  44.       [...]
  45.       This library differs from the    standard malloc    library    in the
  46.       following ways:
  47.  
  48.       1. Each malloc segment contains a magic number so that free
  49.       can verify that the pointer passed points to a valid malloc
  50.       segment.
  51.  
  52.       2. Each malloc segment is filled with    a non-zero pattern so
  53.       that code that depends upon malloc segments being null will
  54.       fail.
  55.  
  56.       3. The size of each segment will be at least 1 byte larger
  57.       than requested and the extra bytes will be filled with a
  58.       non-zero pattern.  When free is called, it will verify that
  59.       you did not go beyond    the number of bytes you    asked for.
  60.  
  61.       4. When a segment is freed, it will be filled    with a
  62.       different non-zero pattern to    ensure that the    program
  63.       doesn't depend upon the use of already freed data.
  64.  
  65.       5. Whenever any of the string    or memory functions (str*, b*,
  66.       mem*)    are called with    a pointer that is within the malloc
  67.       arena,  the operation    is checked to verify that it does not
  68.       overrun the malloced segment.     A failure of this check is
  69.       considered a "warning    level error" (described    later) and is
  70.       handled accordingly.
  71.  
  72.       6. Run time checking can include verification    of the malloc
  73.       chain    at each    and every call to one of the malloc functions
  74.       or manually by calling the malloc_chain_check    function.
  75.  
  76.       7. Extensive support for tracking memory leaks is provided.
  77.  
  78. -- 
  79. Fergus Henderson             fjh@munta.cs.mu.OZ.AU      
  80. This .signature virus is a self-referential statement that is true - but 
  81. you will only be able to consistently believe it if you copy it to your own
  82. .signature file!
  83.