home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #3 / NN_1993_3.iso / spool / comp / lang / cplus / 19736 < prev    next >
Encoding:
Text File  |  1993-01-22  |  2.7 KB  |  66 lines
  1. Newsgroups: comp.lang.c++
  2. Path: sparky!uunet!mcsun!chsun!bernina!litsios
  3. From: litsios@iis.ethz.ch (James Litsios)
  4. Subject: Re: Dangling pointers & suggestions on future implementations of "delete"
  5. Message-ID: <litsios.727695594@iis>
  6. Sender: news@bernina.ethz.ch (USENET News System)
  7. Organization: Swiss Federal Institute of Technology (ETH), Zurich, CH
  8. References: <Jan18.210305.21697@yuma.ACNS.ColoState.EDU> <1993Jan19.193048.15022@borland.com> <1993Jan20.213807.20740@cbnewsi.cb.att.com>
  9. Date: Fri, 22 Jan 1993 09:39:54 GMT
  10. Lines: 54
  11.  
  12. rhw@att.com (Robert Wentworth) writes:
  13.  
  14. >For debugging purposes, I track down memory problems by overloading new
  15. >to store extra information with each object and overloading delete to
  16. >check/update this extra information.  (Also add some code to allow other
  17. >checks).
  18.  
  19. > ...
  20.  
  21. >Anyone else have nifty techniques that they use to root out memory
  22. >problems?
  23.  
  24.  
  25. I have a new and delete redefinition package that essentially does the same
  26. thing with the added cappability of numbering each memory block. I then have
  27. a little input file in which I can set "break points" on specific memory
  28. blocks. For example:
  29.  
  30. B A 2333
  31.  
  32. specifies the when the memory block number 2333 is allocated and freed then
  33. call a predefined function. I then have a real debugger break point on this
  34. function with stops the execution of the program.
  35.  
  36. This feature is really useful because if you run a program twice with the
  37. same input you get same numbering of the memory (this is not always true, but
  38. in that case you are in more trouble) so if you find something strange with
  39. a memory block you get its number and relaunch the program with a break point
  40. on that number you can then figure out when it was allocated, who is accessing
  41. it and if it is being freed too early.  I use this to find memory leaks by
  42. adding break points to all memory block that still exist at the end of an 
  43. execution, I relauch the program and it stops on each allocation that has
  44. no deallocation.
  45.  
  46. Right now I redefine the new and delete operator, but I currently feel very
  47. insecure about this methode because if you redefine the new but not the delete
  48. or the delete but not the new you can end up with more trouble than you had in
  49. the first place.  I now believe that short circuiting the malloc and free
  50. routines is a better way to go.
  51.  
  52.  
  53. >(I suppose I could provide a copy of my code for this, if anyone really
  54. >needs it.)
  55.  
  56. Yes, people do need it. People do not realize how useful this type of tool
  57. is and how much time you gain debugging your code.
  58.  
  59. James Litsios
  60.  
  61. --
  62. James Litsios                   Phone:       +41 1/256 49 50
  63. Integrated Systems Laboratory   Fax:         +41 1/252 09 94
  64. ETH Zurich                      E-Mail:      litsios@iis.ethz.ch
  65. CH-8092 Zurich, Switzerland    
  66.