home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #18 / NN_1992_18.iso / spool / comp / programm / 2338 < prev    next >
Encoding:
Internet Message Format  |  1992-08-15  |  2.8 KB
  1. Path: sparky!uunet!zaphod.mps.ohio-state.edu!magnus.acs.ohio-state.edu!usenet.ins.cwru.edu!agate!jaffna.berkeley.edu!lippin
  2. From: lippin@jaffna.berkeley.edu (The Apathist)
  3. Newsgroups: comp.programming
  4. Subject: Re: When should a debugger be used?
  5. Date: 15 Aug 1992 22:15:49 GMT
  6. Organization: Authorized Service, Incorporated
  7. Lines: 53
  8. Message-ID: <16jvmlINN4j7@agate.berkeley.edu>
  9. References: <j1ymvg=.pdh@netcom.com> <164c9vINNijk@agate.berkeley.edu> <1992Aug12.233904.11067@thinkage.on.ca>
  10. Reply-To: lippin@math.berkeley.edu
  11. NNTP-Posting-Host: jaffna.berkeley.edu
  12.  
  13. From the tinkling keys of atbowler@thinkage.on.ca (Alan Bowler):
  14.  
  15. >What features are in your debuggers that allow you to tract memory
  16. >leaks?  
  17.  
  18. Macintosh debuggers are generally more aware of the heap structure
  19. than debuggers I've seen on other platforms.  This may be because the
  20. heap structure is documented and easy to look at, or it may be because
  21. the OS makes heap-related bugs so common.
  22.  
  23. I'll describe MacsBug here, which is the debugger I generally use for
  24. memory problems.
  25.  
  26. For finding memory leaks, two tools are particularly useful.  One is
  27. the "heap total" command, which lists (among other statistics) the
  28. number and total size of allocated heap blocks.  This is good for
  29. spotting leaks: run through a part of the program a few times, and see
  30. if the numbers grow in ways you don't expect.
  31.  
  32. For fixing the leaks, I use an add-on tool called "leaks" (whose
  33. author I should credit, but I don't have the name handy).  When turned
  34. on, it records block allocations and disposals.  It records the call
  35. chain of the allocations, and groups those with similar call chains
  36. and sizes.  The effect is wonderful -- I run the program for a while,
  37. and it points out the code that allocates leaky blocks.
  38.  
  39. For other heap related problems there are features worth pointing out:
  40.  
  41. It can run a consistency check on the heap structure.  This will
  42. often catch writes to locations just outside a block.
  43.  
  44. It will (with some difficulty) tell you the stats of a block you're
  45. interested in.  This is particularly useful when you think you may be
  46. referencing a freed block.
  47.  
  48. It can be set to break on or record particular system calls (with a
  49. few limitations).  It's a good way to find the spot where you're
  50. enlarging that memory block, among other problems.
  51.  
  52. It can use the processor's trace mode to break on a change to a
  53. particular memory location.  This helps find writes through wild
  54. pointers.  On a 68040, the processor caches will allow this to run at
  55. a respectable speed.
  56.  
  57. The program being run can issue debugging commands.  This helps one
  58. get a handle on some of the more twisted bugs, particularly those that
  59. only happen in real time.
  60.  
  61.                     --Tom Lippincott
  62.                       lippin@math.berkeley.edu
  63.  
  64.          "Come see the violence inherent in the system!"
  65.                 --Dennis, "Monty Python and the Holy Grail"
  66.