"delete" causes a crash

When I "delete" an array created by "new" I get a fatal error saying that there is damage after block 98. Does anyone have an idea of how I can figure out what is causing that error?

Is there anything else that can cause the error besides an overwrite?

The error happens when I increase the sampling rate of the soundcard. I think (hope) that all arrays have been scaled appropriately. The error occurs after the second deletion of an object that has all these fields using the higher sampling rate (at lower sampling rates there is no problem). The first time I delete and recreate the object its okay. The second time it crashes.

(I do use the "NULL" test to keep track of whether a memory block has been created by "new" and deleted by "delete".)

Any hint on even how to look for this error would be greatly appreciated. (Using VC++ 6.0).

Thanks,

Brian

Look at the memory right after the array, if the guard codes have been destroyed, you have damage. Sometimes the data is recognizable....

Good luck.

It's hard to say anything without a prior look on the code.

I hope you are using new/delete in the appropriate way, i.e. allocate with new, release with delete, alocate with new [], release with delete [].

are you writing off the end of the array somewhere? (sometimes this is less obvious than it sounds)

Yes, I am pretty sure I am doing an overwrite somewhere. Its just pretty hard to catch it. (I am using the new C++ "new" and "delete" operators). I was wondering if anyone had any techniques to help find it.

Brian

post the code?

use the crt functions <crtdbg.h>

1) Sprinkle _CrtCheckMemory(...) calls around the code you suspect is causing the issue.
2) watch the memory location in the memroy window, the debug CRT pads 4 bytes before and after with 0xFD as a guard. So you can watch the beginning or end of the memory location for those bytes being overwritten.
3) Set a data breakpoint via the breakpoints, plug the addresses in. When you get the damage after normal block you should be getting a CRT message box plus output in the debug window output that shows the address. When you have a data breakpoint it will break when you write that location so you can verify what you are doing at that point is not overwriting.
4) In your program init (main/dllmain/global c++ ctor) you can make a call to _CrtSetDbgFlag(...) and turn on _CRTDBG_ALLOC_MEM_DF and _CRTDBG_CHECK_ALWAYS_DF the later will make calls to _CrtCheckMemory(...) automagically for you in new/delete pairs (don't leave it on unless you want to give your debug build code a shake-down becaues it will be a bigger performance impact and can cause you to miss sync problems)

Download a trial copy of IBM Rational PurifyPlus or Compuware Numega, install it, run your program and check for problems.
It's faster and safer than modifying your program.

Thingol, I'll do that! Always wished there was a third party that could look at my code. I have spent years writing code by myself and we all know where that leads...narrowness of approach and concepts.

I have actually found the problem but I am not sure how it caused an overwrite.

Brian

Quote:

---

I have actually found the problem but I am not sure how it caused an overwrite.

---

Then you have note rally found the problem.... ;)

Reminds me of a person who once compained that his computer kept crashing with a BSOD. He removed all of the partitions from the hard drive and has not had a single crash since...

You are entirely correct... I may not have. But the error may not be due to an overwrite. I have a high priority thread here doing a load of DSP computations, and I slipped though a bug of letting the sample rate not be an integral multiple of the baud rate (I thought I checked for that).

In any case, the non integral values cause the signal timing to get out of sync in the DSP routines and I think that may have caused some serious problems. How it does it I don't know, but I DO know that non integral values will cause lots of problems on the mathematics!

Brian

Quote:

---

Originally Posted by Gyannea

But the error may not be due to an overwrite.
Brian

---

The message your getting is coming from an explicit check inside of the CRT memory routines that checks for overwrites. Even if you manage to get there by munching on the stack, you've still done an overwrite.

Code:

---

if (!CheckBytes(pbData(pHead) + pHead->nDataSize, _bNoMansLandFill, nNoMansLandSize))
                _RPT3(_CRT_ERROR, "DAMAGE: after %hs block (#%d) at 0x%08X.\n",
                    szBlockUseName[_BLOCK_TYPE(pHead->nBlockUse)],
                    pHead->lRequest,
                    (BYTE *) pbData(pHead));

---

As far as rationals purify and compuwares boundschecker...if you have the money then pick one up. I have used purify since the 90's and it is fairly decent. Though you can find these errors without them by understanding the tools that are available to you. If the purify demo is still the same it should be able to find this easily.

www.rational.com
www.compuware.com

I just realized how expensive these tool were. I don't even BEGIN to have the money. I will need other tools!

Brian