I thought it could be useful to explain how we use MemCheck everyday at work.
Everyone in the team is always working on the project with MemCheck active and supervising memory usage (of course there can
be exceptions for specific reasons such as performance measuring, etc.). Of course it is configured for this; for example, every
block freed by the program is really freed by MemCheck (unfortunately this makes the use of destroyed objects not checked). We have
to do this because our program uses a lot of memory in normal conditions.
Most people don't know they are working with MemCheck; some even don't know what it is. This is because it is silent as long as
there is no problem. Sometimes they will come and ask "why is there a strange file opening in notepad when I close the program ?".
When there is a hard to solve bug (I don't mean a memory leak), I typically change the settings of MemCheck. The main thing I change is to have MemCheck check the use of destroyed objects (by setting DeallocateFreedMemoryWhenBlockBiggerThan to MaxInt). A lot of bugs are due to using an object after its freeing (you know, when you try to access MyObj.ClassName and you get a strange string). With this change, when you use a destroyed object (to be precise, when you call a virtual method), MemCheck will tell you "hey, this has already been destroyed at line xxx of unit uuu ! And by the way, this had been allocated at line yyy of unit vvv". And also, if you ask for a destroyed object's classname, it will be TDestroyedObject, which is helpful.
A last word: we turn MemCheck off for published versions of the program. MemCheck decreases a little the program performance (definitely a little, but of course that depends on the MemCheck settings and on how much memory allocations and deallocations the program does). We have however made it available for the end-user to turn on. This is useful when a problem occurs at the user's site and memory leaking is suspected and we can not reproduce the problem.
Last update: March 2001