home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #18 / NN_1992_18.iso / spool / comp / programm / 2291 < prev    next >
Encoding:
Text File  |  1992-08-12  |  1.4 KB  |  35 lines
  1. Newsgroups: comp.programming
  2. Path: sparky!uunet!zaphod.mps.ohio-state.edu!cs.utexas.edu!torn!watserv2.uwaterloo.ca!watmath!thinkage!atbowler
  3. From: atbowler@thinkage.on.ca (Alan Bowler)
  4. Subject: Re: When should a debugger be used?
  5. Message-ID: <1992Aug12.233904.11067@thinkage.on.ca>
  6. Organization: /etc/organization
  7. References: <j1ymvg=.pdh@netcom.com> <164c9vINNijk@agate.berkeley.edu>
  8. Date: Wed, 12 Aug 1992 23:39:04 GMT
  9. Lines: 24
  10.  
  11. If I have a debugger available I will try it first before I go the
  12. "add debugging printf and recompile" route.  I will even go to some
  13. effort to maintain a "simulated" environment where I can run a debugger
  14. if I don't have a debugger in the actual target environment.
  15.  
  16. I prefer to use a debuggers.
  17.  
  18. However, I am intrigued by the following statement.
  19.  
  20. In article <164c9vINNijk@agate.berkeley.edu> lippin@math.berkeley.edu writes:
  21. >
  22. >Some bugs (e.g., memory leaks) are very nearly intractable without
  23. >debugging tools, simply because they show few visible symptoms in
  24. >ordinary test conditions.
  25. >
  26.  
  27. Memory leaks are one of the areas where I have found debuggers to be
  28. very little use.  I do use it to examine the free memory list, and say
  29. to myself "this look suspiciously large", but that just tells me there
  30. MIGHT be a leak.  Finding the actual is has always been more of
  31. an analysis problem.
  32.  
  33. What features are in your debuggers that allow you to tract memory
  34. leaks?  
  35.