Sign in to follow this  
Uphoreum

RtlValidateHeap Error

Recommended Posts

I have a game state stack that I'm using to store game states. When the program is closed, all the states left on the stack are popped off and deleted. The problem is that I get an "Invalid address specified to RtlValidateHeap" when the 'delete' line is encountered. The stack stores pointers to the base state class (from which concrete state classes are derived) like this: std::stack<State*> During cleanup, I remove the states like so: while (!m_states.empty()) { State *pState = m_states.top(); m_states.pop(); delete pState; // This is the problem line. } I checked and pState is not NULL or anything at the point of 'delete'. It seems to be a valid address and it is the same address as that particular state pointer is when it is first pushed into the stack. My only thought is that maybe the stack's pop method already deleted the pointer? I did something just like this a while ago and didn't have any problems. I'm really not sure what's going on. Anyone have any ideas or know of other info I should give? I'm wondering if I did something somewhere else that indirectly screwed things up by "corrupting the heap" (I heard that somewhere, but I'm not entirely sure how you corrupt the heap).

Share this post


Link to post
Share on other sites
Okay, I'm guessing this is pretty important.

The whole game state stack code is part of a framework DLL, so I thought maybe the DLL was causing problems.

I set it up and compiled it as a static library instead and linked to the static library with my test app.

As I thought, I no longer had the problem.

Anyone know why the DLL might be acting up in this strange way when the static lib doesn't?

Share this post


Link to post
Share on other sites
The EXE and DLL might have different heaps, if you allocate memory from one heap, it needs freed from that heap.

If you're linking to the DLL version of the CRT (Which is the default in VC2005, 2008 and I assume 2003), then both the EXE and DLL will use the same heap (The one in the DLL), so all is well. If you're statically linking to the CRT, then you get one version of the code in the EXE, and one version in the DLL - I.e. two different heaps.

If you're using the DLL version of the CRT, you also need to make sure that you have the same version for the EXE as you do the DLL, since if the versions differ, the heaps will be different.

The safest way is to make sure that any memory allocated in the DLL is freed in the DLL, and similarly for the EXE. It's also worth noting that passing STL objects across a DLL boundary by value or non-const reference (or pointer) is A Bad Thing, since they can perform [de]allocations internally.

Share this post


Link to post
Share on other sites
Is the Code Generation->Runtime Library property of the project the version of the CRT I'm linking with? In that case, the EXE is linking with "Single-threaded Debug" (not DLL I guess) and the DLL is linking with "Multi-threaded Debug" (Again, not DLL I think).

If the Runtime Library property is not the CRT version, where can I find that?

And now that I think about, I am allocating memory in the EXE and deleting it in the DLL. Will that still be a problem even if they are both using the same CRT?

Share this post


Link to post
Share on other sites
Quote:
Original post by Uphoreum
Is the Code Generation->Runtime Library property of the project the version of the CRT I'm linking with? In that case, the EXE is linking with "Single-threaded Debug" (not DLL I guess) and the DLL is linking with "Multi-threaded Debug" (Again, not DLL I think).

If the Runtime Library property is not the CRT version, where can I find that?
Yup, that's the one. They should probably be set to DLL versions.

Quote:
Original post by Uphoreum
And now that I think about, I am allocating memory in the EXE and deleting it in the DLL. Will that still be a problem even if they are both using the same CRT?
That depends. If the DLL and EXE use the same version of the DLL CRT, it'll be fine. But if you ever find you need to update the DLL, you'll have to either make sure you're using the same version as you used to build the EXE, or you'll have to update the EXE too.
That might be a problem if you're using DLLs to make things more modular. It also makes it almost impossible for you to develop a library as a DLL and then only release the .dll, .lib and .h files for other people to use, since they'll have to make sure they have the exact same version of the CRT as you used.

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