Game Development Reference
In-Depth Information
If you happen to write your own memory manager, make sure that you take the time
to write some analogs to the C runtime debug heap functions. If you don
'
t, you
'
ll
find chasing memory leaks and corruptions a full-time job.
Don
'
t Ignore Memory Leaks
—
Ever
Make sure that your debug build detects and reports memory leaks, and
convince all programmers that they should fix all memory leaks before they
check in their code. It
'
s a lot harder to fix someone else
'
s memory leak than
your own.
COM objects can leak memory, too, and those leaks are also painful to find. If you
fail to call
Release()
on a COM object when you
re done with it, the object will
remain allocated because its reference count will never drop to zero.
Here
'
'
s a neat trick. First, put the following function somewhere in your code:
int Refs (IUnknown* pUnk)
{
pUnk->AddRef();
return pUnk->Release();
}
You can then put
Refs(myLeakingResourcePtr)
in the watch window in your
debugger. This will usually return the current reference count for a COM object. Be
warned, however, that COM doesn
'
t require that
Release()
return the current ref-
erence count, but it usually does.
Most memory corruptions are easy to diagnose. Your game crashes, and you find
funky trash values where you were used to seeing valid data. The frustrating thing
about memory corrupter bugs is that they can happen anywhere, anytime. Since the
memory corruption is not trashing the heap, you can
t use the debug heap functions,
but you can use your own homegrown version of them. You need to write your own
version of
_CrtCheckMemory()
, built especially for the data structures being van-
dalized. Hopefully, you
'
ll have a reasonable set of steps you can use to reproduce the
bug. Given those two things, the bug has only moments to live. If the trasher is inter-
mittent, leave the data structure check code in the game. Perhaps someone will begin
to notice a pattern of steps that cause the corruption to occur.
'
