By excercising your code and observing the entries in the table you
can
identify locations that are likely to allocate blocks that never get
freed.
You need to launch the app you wan't to leakcheck from the Terminal.
To activate the leakchecker, place calls to:
SetNewLeakChecking(true);
SetMallocLeakChecking(true);
from:
LeakChecking.h
somewhere early on in your app, for instance in main or in your BApplication
constructor or main function and you are ready to leakcheck. You may
selectively choose to only leakcheck new/delete or malloc/realloc/free
by
only turning on one of the leakcheckers.
Unless you turn the leakchecker on explicitly the overhead of the leakchecking
code is very small, you won't notice a slowdown. Even with the leakchecker
activated the slowdown is not very big.
The malloc leakchecking table prints a three level call chain leading
to
the allocation, that way you can better pinpoint where your allocation
was
initiated. The new leakchecking table currently only prints the immediate
caller. This is to cut down on table size and can be easily changed.
Typically you will use the terminal debugger (db) to examine the different
call locations, an xMAP also works, it's just harder to pinpoint the
library addresses.
Note that the leakchecker checks every allocation in your app, including
allocations in the kit classes so you might be seeing some leaks caused
by
the kit classes rather than by your own code.
The leakchecker will detect when there is an attempt to free or delete
an
object that wasn't malloc'd or new'd respectively. This may happen
if you
say allocate an object with new and later delete it with free, which
is a
Very Bad Idea (TM). Also, it may get thrown off by statically allocated
objects - these get allocated before the leakchecker gets turned on
in main.