Sign in to follow this  

Memory deletion bug

This topic is 3592 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Hi there, I have a memory deletion bug in C++, When I try to delete the memory I have dynamically allocated I get a debug assertion error. This is what comes up "Debug assertion failed, dbgdel.cpp, Line 52, _BLOCK_TYPE_IS_VALID(pHead->nBlockUse). All my other variables delete without a hitch, does any body know why this assertion is failing?

Share this post


Link to post
Share on other sites
We'll need to see some code I think. It sounds like you're deleting an uninitialised pointer, you're double-deleting something, or you're deleting a stack variable.

If you look at the value of the pointer when it asserts (In the debugger, go up the call stack till you get to your code, and see what the value is in the watch window) in hexadecimal, what's it's value? The compiler usually fills variables with meaningful patterns in debug builds and if it looks suspect (E.g. 0xcccccccc, 0xcdcdcdcd, 0xbaadf00d, etc), we can guess what the problem is.

Share this post


Link to post
Share on other sites
void CGame::AllocMemory()
{
m_pTable = new Table;
}

void CGame::FreeMemory()
{
delete m_pTable;
}

I'm definitely not deleting it somewhere else and I've checked the pointer before deletion, it is valid. I am using multiple threads in this application, could that be causing this?

Share this post


Link to post
Share on other sites
What that error message is telling you is that something has trashed memory near that pointer.

To track down where I'd recommend putting this at the first line of main:

_CrtSetDbgFlag(_CRTDBG_ALLOC_MEM_DF | _CRTDBG_CHECK_ALWAYS_DF | _CRTDBG_DELAY_FREE_MEM_DF | _CRTDBG_LEAK_CHECK_DF);

What it will do is cause the runtime to check the entire heap for corruption at every new and delete. Your program will then stop at the first memory allocation after the heap has been corrupted.

This can make your code run very slow if you do lots of allocation, so be patient. Alternatively just use the _CrtCheckMemory() asserts.

To narrow it down even further you can add ASSERT(_CrtCheckMemory()); statements around the code. That will assert if the heap is corrupted so it'll let you narrow down the statement that corrupts the heap (i.e. find the statement where it doesn't assert before executing it, but does assert after).

You may need to #include <crtdbg.h> for those to compile. Also make sure it's a debug build or they'll do nothing.

See http://msdn2.microsoft.com/en-us/library/5at7yxcs(VS.71).aspx for more details.

Share this post


Link to post
Share on other sites
Quote:
Original post by Spriggan82
void CGame::AllocMemory()
{
m_pTable = new Table;
}

void CGame::FreeMemory()
{
delete m_pTable;
}

I'm definitely not deleting it somewhere else and I've checked the pointer before deletion, it is valid. I am using multiple threads in this application, could that be causing this?
Make sure the pointer is set to null in the constructor, and after deleting it. You should always do that with pointers anyway. If the bug still persists, then it's probably not double deletion or deleting an uninitialised pointer.

If you're using threads, are you using mutexes to prevent your code ending up calling FreeMemory() twice at onec from two threads? That could certainly cause this sort of bug (Although it'd likely be intermittant)

Share this post


Link to post
Share on other sites
The cause of memory corruption is likely to be one of:

- Array indices out of bounds.
- Using something after deleting it.
- Buffer overruns (strcpy, memcpy, etc).
- Misuse of pointers.
- Thread synchronization problems.

If you can't narrow it down to one line of code with the assert(_CrtCheckMemory()) calls then it's most likely not being corrupted on the thread that your asserting on. You should put the tests on one thread at a time, or it'll just make it harder to find.

Also have you got the compiler settings (runtime library) set as multi threaded? If not that can cause all sorts of problems.

Share this post


Link to post
Share on other sites
Quote:
Original post by Spriggan82
void CGame::AllocMemory()
{
m_pTable = new Table;
}

void CGame::FreeMemory()
{
delete m_pTable;
}

Ah, consider this.

int main(int, char*[])
{
CGame game1;
CGame game2 = game1;
}

Can you spot where the application will crash in the above code snippet?

Share this post


Link to post
Share on other sites
Quote:
Original post by Spriggan82
void CGame::AllocMemory()
{
m_pTable = new Table;
}

void CGame::FreeMemory()
{
delete m_pTable;
}


Is there a reason you don't want the m_pTable to be allocated for the whole time that the CGame object exists? RAII is your friend.

Share this post


Link to post
Share on other sites

This topic is 3592 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

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