Sign in to follow this  
CastorX

Assert

Recommended Posts

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[i]->Path; allocation: Textures[i]->Path = new WCHAR[PL + 1]; The new function was successful. How can I heal this?

Share this post


Link to post
Share on other sites
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!

Share this post


Link to post
Share on other sites
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?

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
I think Evil Steve is right here. There may be a buffer overflow before the delete, wich overwrite the internal structure of the heap. When the CRT try to free the allocated memory, it detect the corruption and cause the error. I remember there is an option in VC++2005 to detect buffer overflows at runtime, but I don't know if it works for arrays created with new.

Share this post


Link to post
Share on other sites
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;
}


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

What happens with:

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

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this