   Best way to find allocation/access errors?
  I have a nuisance error in my program - whenever the program is ended I get an access violation error.  I'm pretty certain the problem lies in the heap somewhere as occasionally the debugger will show the heap code for debugging (and sometimes it just shuts down the program and returns me to my previous view).  I've been going oiver and over my code and can't see any memory problems - everything that gets created gets destroyed.  There's very little being used as globals (just a few instance pointers and a couple of integers).Are there any tools/libraries/run-time methods that could help me trace this problem more accurately? (C++)  Step debugging doesn't seem to be working - everytime I step debug through the shut-down it works perfectly.[edited by - damocles on February 10, 2004 6:49:40 PM]
  Are you using Visual C++? If you are then try using the CRT Debug Heap (look for ''debug heap'' in the MSDN index). This is very helpful for tracking down memory problems. If you''re not using VC then take a look at Paul Nettle''s Debug Memory Manager - there''s also a similar debug memory manager presented in one of the Game Programming Gems books (can''t remember which, think it''s probably the first one). ;  I am using VC++.  I looked through the MSDN files on the debug heap and would just like to say that I am impressed.  Impressed that Microsoft can fill pages on the subject and still leave me with no clue as to how to use the feature. >I managed to learn how the debug heap works, but the msdn stuff doesn''t seem to give any information on how to actually put the debug heap to use, only what it does.So after that I decided to try that memory management code you linked.  I think this could be a really useful tool - except it''s doing strange things.  Even in normal, non-stress test mode it''s flagging asserts in very strange places.  For instance, it falgs an error when I attempt to create a new instance of a class.  A simple line like:Config* config = new Config;flags an error where the comments say that the program is trying to allocate memory that it shouldn''t be.  Youwahh?  Is there any more info on using the memeory manager other than the cpp comments?  It seems like it could be really useful if I could figure out why the most basic commands are flagging asserts. ;quote:I am using VC++. I looked through the MSDN files on the debug heap and would just like to say that I am impressed. Impressed that Microsoft can fill pages on the subject and still leave me with no clue as to how to use the feature. >I managed to learn how the debug heap works, but the msdn stuff doesn''t seem to give any information on how to actually put the debug heap to use, only what it does.IIRC, all you have to do is use the debug version of the CRT (just compile in debug mode).   ~nz // Website // Google // GameDev // NeHe // MSDN // OpenGL Extensions // ;  Personaly I don''t know why people have such trouble with MSVC memleak tools. It takes like 5-10 lines to set it up.   You should never let your fears become the boundaries of your dreams. ;  I saw how to turn on the debug versions of the heap CRT.  However, what does this do?  It says in the information that it adds extra identification bytes to all allocations, but I couldn''t see anything about how to use these ID bytes to track problems. ;  When program exits it prints out a list of memleaks and their allocation ID. Use this ID in _CrtSetBreakAlloc() to find it in code.something like:int tmp = _CrtSetDbgFlag( _CRTDBG_REPORT_FLAG );// get the current bitstmp &= 0x0000FFFF;// clear the upper 16 bitstmp |= 0x00010000;// and OR in the desired freqencytmp |= _CRTDBG_CHECK_ALWAYS_DF;// all checkstmp |= _CRTDBG_LEAK_CHECK_DF;// dump mem leaks_CrtSetDbgFlag( tmp );// set the new bits//_CrtSetBreakAlloc( 51 );// break at allocation  You should never let your fears become the boundaries of your dreams. [edited by - _DarkWIng_ on February 12, 2004 4:11:55 AM]