Sign in to follow this  
  • entries
    149
  • comments
    510
  • views
    94472

Buggin Out!

Sign in to follow this  
noaktree

99 views

Spent most of my day tracking down an obscure bug in my material editor. It was appearing to crash at random. Cause: There was corrupt data at a memory address. Turned out that I was accessing a dynamic array with a -1 index every once in a while and this corrupted the pointer so that when I went to delete [] the array the app crashed. Glad that's over. Thanks to the good old OutputDebugString().

Added individual subset selection using the mouse and extended list box. The interface is turning out really nice. Next I'll need to clean up and reorganize my modules cuz things are starting to get a little out of control [smile].
Sign in to follow this  


5 Comments


Recommended Comments

You could've avoided the trouble in the first place with vector's at member that throws an exception on out-of-bounds access attempts [smile].

Also, scattering _CrtCheckMemory() calls throughout your code can quickly help you identify the source of heap corruption.

My 2 cents [smile]

Share this comment


Link to comment
Thanks Coder!

edit: So are you saying that we shouldn't use dynamic arrays? Or just that we should use some sort of container if we do?

edit2: Yes I now see using _ASSERTE with _CrtCheckMemory() will be very usefull for apps made with VC++! [smile]

Share this comment


Link to comment
Quote:
edit: So are you saying that we shouldn't use dynamic arrays? Or just that we should use some sort of container if we do?

Basically, in C++, you should almost always use std::vector instead of raw arrays. And always use std::vector::at() to access elements, because it does bounds-checking. If profiling shows std::vector::at() is a bottleneck somewhere (in some oft-used inner-loop), switch to std::vector::operator[](), which simply generates code equivalent to what would have been generated with direct access to the raw array (i.e. no performance hit).

Bjarne - The Man (TM) - says it all. Read everything the guy has to say [smile]

Quote:
edit2: Yes I now see using _ASSERTE with _CrtCheckMemory() will be very usefull for apps made with VC++!

You can also make use of _CrtSetDbgFlag for memory-leak tracking - it makes it a breeze (plug "Detecting and Isolating Memory Leaks Using Microsoft Visual C++" into google and read the MSDN article that comes up [smile])

Share this comment


Link to comment

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