Pavel's leakchecker

The leakchecker checks new and malloc allocations separately and
periodically prints out a table of the 20 locations in the code with most
outstanding (undeleted/unfreed) allocations the terminal. It also
prints the total of outstanding allocations, the size of the outstanding
allocated blocks and a per call address total size of blocks. Currently
the table is sorted by number of calls, it may be more usefull to sort it
by the ammount of allocated space for some applications and would be
easy to do so.

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.