🔒 Locked

Assert

Started by CastorX Apr 24, 2006 at 4:53 AM 12 replies 2.4k views

Original Post

Apr 24, 2006 at 4:53 AM

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?

Jan Wassenberg

105

Jan Wassenberg

Apr 24, 2006 at 4:56 AM

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.

CastorX

Author

CastorX

Apr 24, 2006 at 5:06 AM

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!

Spoonbender

123

Spoonbender

Apr 24, 2006 at 5:08 AM

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"

CastorX

Author

CastorX

Apr 24, 2006 at 5:21 AM

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?

Evil Steve

382

Evil Steve

Apr 24, 2006 at 5:28 AM

Looks like Texture is 0xfeeefeee

CastorX

Author

CastorX

Apr 24, 2006 at 5:32 AM

False, man! :)
Nothing is feeefeee! That's the problem!

Nuno1

Apr 24, 2006 at 5:45 AM

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

Evil Steve

382

Evil Steve

Apr 24, 2006 at 5:49 AM

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.

CastorX

Author

CastorX

Apr 24, 2006 at 6:20 AM

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.

Evil Steve

382

Evil Steve

Apr 24, 2006 at 6:34 AM

There's _CrtDumpMemoryLeaks, but this isn't caused by memory leaks. Memory leaks won't cause your program to crash (unless it's from failing to allocate memory).

Also bare in mind that _CrtDumpMemoryLeaks will show all unalocated memory including STL allocations that will usualyl be freed when the application exits.

NotAYakk

Apr 24, 2006 at 9:19 AM

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

Step 1: Remove the "..." code.

What happens with:

Texture->Path = new WCHAR[PathLength];if (Texture->Path != NULL) {  delete[] (Texture->Path);  Texture->Path = NULL;}

VladR

Apr 24, 2006 at 10:14 AM

Also, to check the adresses, make sure you are setting the pointers at startup to NULL. This is best accomplished by constructor - thus any object created shall have the pointer set to null. Then, trace the program step by step to see when the adress changes (or just try releasing it every few lines until it crashes again to spot the place which is the origin of bug), because something overwrites it. Only you can debug it. It`s a slow and painful process, but it can be done only by you.

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.