home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #30 / NN_1992_30.iso / spool / comp / lang / cplus / 17845 < prev    next >
Encoding:
Text File  |  1992-12-11  |  1.5 KB  |  40 lines
  1. Newsgroups: comp.lang.c++
  2. Path: sparky!uunet!microsoft!hexnut!jimad
  3. From: jimad@microsoft.com (Jim Adcock)
  4. Subject: Re: new returns address it already returned!
  5. Message-ID: <1992Dec11.220827.6197@microsoft.com>
  6. Date: 11 Dec 92 22:08:27 GMT
  7. Organization: Microsoft Corporation
  8. References: <Bz24B3.62A@news.cso.uiuc.edu>
  9. Lines: 29
  10.  
  11. In article <Bz24B3.62A@news.cso.uiuc.edu> dmd39855@uxa.cso.uiuc.edu (Daniel DuBois) writes:
  12. |Anybody know what the heck is going on?  Why in heck would new return the
  13. |same address?
  14.  
  15. Two common ways for this to happen are:
  16.  
  17. 1) A delete has been called on the prior allocation, freeing the block to
  18. be reused by new.
  19.  
  20. 2) A delete has been called incorrectly on somw prior allocation, corrupting
  21. the heap, leading new to think the block in question is free to be reused by
  22. new.
  23.  
  24. Common ways to corrupt the heap include:
  25.  
  26. * Using polymorphism and news/deletes without declaring virtual destructors.
  27.  
  28. * Mixing up new/delete with new[n]/delete[]
  29.  
  30. * writing off the end of an allocation.
  31.  
  32. As a test, I suggest if at all possible start by commenting out ALL of
  33. the delete statements your program uses.  Not some, ALL of them.  This
  34. is only possible to do if your program makes reasonably bounded use of
  35. heap.  If you can do this, and if doing so causes your bug to go away,
  36. then your error is in one or more of the delete statements [or side-effects
  37. they cause]  The question then simply becomes which one[s] to fix.
  38. Note that MFC has a debugging new/delete option that is frequently useful
  39. in tracking down allocation problems.
  40.