Jump to content
  • Advertisement
Sign in to follow this  
d000hg

Wierd crash bug

This topic is 4835 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

My game keeps crashing in debug build, but apparently on my XP machine at work. On my Win2K PC at home there are no problems. In release mode it's also pretty good on all PCs I tried. The crash keeps happening when I do std::vector.push_back(MyObject). Sometimes I just get a crash, othertimes I get told a user defined breakpoint has been reached - on F5'ing to continue I get the same error - First-chance exception in 4E4_RTS.exe: 0xC0000005: Access Violation. I also get this debug information Heap corruption detected at 00A07CA0 HEAP[4E4_RTS.exe]: HEAP: Free Heap block a07c98 modified at a07ca8 after it was freed Now I am kind of thinking the crash is elsewhere since sometimes the debugger goes nuts, but perhaps I should check... I am pushing back an object to the vector, not a pointer. It's only a very small class so this is OK, but I provide no copy constructor. This should be safe if the class doesn't use pointers right? And push_back(0 does actaully invoke a copy constructor? Otherwise I'm stumped. Why only on certain PCs, and it didn't always do it but I can't remember what changed :(

Share this post


Link to post
Share on other sites
Advertisement
Here's my best guess as to what is happening, but it's just a guess:

Ok, in debug mode some compilers, including MSVC, tend to make malloc()/free()/operator new/operator delete wrappers around the OS functions HeapAlloc()/HeapFree(). On XP, when you request an allocation that is not a multiple of 8, HeapAlloc() allocates the size rounded up to the next size of 8. However, the unused bytes at the end are used for heap consistency checks. So if you have a small buffer overrun XP may detect the buffer overrun as heap corruption and generate an exception. I don't recall the details but this behavior does differ from OS to OS. IIRC, XP Pro and XP Home both do the check, but 2000 Home doesn't.

So most likely you have a small, 1 to 4 byte, buffer overrun somewhere in your code that is relatively benign in release mode (overruning into a non-heap consistency over allocation area). It's also likely that the push_back() is occuring after the damage and the actual push_back() call is fine.

Share this post


Link to post
Share on other sites
How on earth do I track something like this down? I did once try to use Paul Nettle's MMGR code but couldn't get it working on more than a few of my source files.
Is there something akin to a profiler that tracks memory perhaps? Obviously the debugger isn't up to it!

Share this post


Link to post
Share on other sites
Check to make sure that none of your arrays are overflowing, and don't delete memory allocated by a DLL with delete or any other memory dealocation routines, use the delete method the DLL provides. Those two in my experience have been the hardest bugs to find. I have an array overfloaw somewhere in one of my projects, but it only appears in release builds.

Share this post


Link to post
Share on other sites
Are you pushing the actual object rather then reference to an object? If you are, I would start looking at your constructors and any overloaded assignment operators you've done. If possible test those operations outside the vector.

Share this post


Link to post
Share on other sites
I guess it's worth a look. The actual class definition for objects I push onto a std::vector are:
class RenderState
{
public:
D3DRENDERSTATETYPE m_State;
DWORD m_Value;
RenderState(D3DRENDERSTATETYPE state,DWORD value) : m_State(state),m_Value(value)
{}
};
class TextureStageState
{
public:
DWORD m_Stage;
D3DTEXTURESTAGESTATETYPE m_State;
DWORD m_Value;
TextureStageState(DWORD stage,D3DTEXTURESTAGESTATETYPE state,DWORD value) : m_Stage(stage),m_State(state),m_Value(value)
{}
};
Nothing wrong here I think?
I basically do for example:
vector.push_back(RenderState(D3DRS_ALPHABLENDENABLE,TRUE));

How in general can I track down heap errors? I get the address of the memory in the debug output but how do I find the variable at that address for instance? The crash actually happens deep in the bowels of the stl, in some function called "_CreateInstance" or something like that. But are memory leaks the kind of thing where it always did it, and changing something elsewhere in the code suddenly gets it noticed - or are they straightforward to search for?

Share this post


Link to post
Share on other sites
Those classes should be able to rely on default implementation of things, I mean an enumerated type and a dword hardly is taxing. From what you've shown I can't see anything wrong. You could move initalisation to a different line using an object rather then using an anon instance I guess.

Or you could try this I suppose, as your class really is just plain old data (though I'm not sure warts make much sense in POD)


struct RenderState
{
D3DRENDERSTATETYPE m_State;
DWORD m_Value;
};

RenderState state={D3DRS_ALPHABLENDENABLE, TRUE};
vector.push_back(state);




About that heap error thing... Visual C++ 6 had something called "goto" and that had "goto memory address" - though I can't find it in Visual C++ 2003. Having as many debug symbols as you can available can help browse to things too.

Share this post


Link to post
Share on other sites
I think I confirmed it is my state manager which causes problems. In this post I have my code for it - anyone taking a look would be in my good books and some ratings will showered upon them like confetti!

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!