Assert

Started by
12 comments, last by VladR 17 years, 11 months ago
Hy! The VC++2005 debugger has written: Heap corruption detected at 003C5698 First-chance exception at 0x7c926a36 in WeDidIt.exe: 0xC0000005: Access violation writing location 0xfeeefeee. by this line: delete[] Textures->Path; allocation: Textures->Path = new WCHAR[PL + 1]; The new function was successful. How can I heal this?
Advertisement
0xFEEEFEEE is freed memory, so you're probably doing delete[] twice.
Easiest way to avoid this is always setting the pointer to 0 after delete-ing.
E8 17 00 42 CE DC D2 DC E4 EA C4 40 CA DA C2 D8 CC 40 CA D0 E8 40E0 CA CA 96 5B B0 16 50 D7 D4 02 B2 02 86 E2 CD 21 58 48 79 F2 C3
Hey!
I tried it!
The FeeeFee adress is comes after delete[], and I did anything... =NULL after delete[] and ...!= NULL then delete ... Before the delete function the adress of the array is NOT NULL or FeeeFeee. That is the problem!
Sure. Addresses are only null if you set them to null yourself.
Otherwise, they're just "whatever random data happened to be at that memory location"
Sorry this is CORRECT:
Full code: (with some pseudo)

...
Texture->Path = new WCHAR[PathLength]
...
if(Texture->Path != NULL)
{
//At his point Texture->Path is 0x003c55e8
delete[] Texture->Path; //Here comes the error message
//At his point the adress is NOT 0xfeeefeee or NULL, it's again 0x003c55e8
Texture->Path = NULL;
}

ERROR:
Heap corruption detected at 003C5650
First-chance exception at 0x7c926a36 in WeDidIt.exe: 0xC0000005: Access violation writing location 0xfeeefeee.

What can I Do now?
Looks like Texture is 0xfeeefeee
False, man! :)
Nothing is feeefeee! That's the problem!
castorX,
please post the Stack trace of your sharing violation (copy the stack window)

also it will be easyer if you will take the serveal lines of assembly code from the disassembly window and show them to us + the registers values.

I am sure this is somthing very easy to catch, you are not providing the full source code so it is allways a guess to know exactly where the problem is.

Cheers,
Nuno1
Ok, another guess - you're overwriting the bounds of your array, and that's screwing up the CRT enough to cause the access violation. You're definitely overwriting your array, there's the message in the debug output that says so. Are you remembering to leave room for the NULL, and are you remembering that a WCHAR is 2 bytes?

As Nuno1 says, we really need to see the full code to help further.
I'm not sure, but...
It's able, that the problem is not here. It's somvehere in an other dinamically allocated class. Thanks! I'm working on it. I herad, there is a special method to see the not-freed memory after runnig is it true? Perhaps I forget to free some mem.

This topic is closed to new replies.

Advertisement