Memory leaks are some of the trickiest things to track down when you are writing programs. Somewhere you allocate a chunk of memory and then later on, that memory isn’t freed when it’s no longer needed. Small memory leaks might not be a problem but when a program allocates huge amounts of memory, you can run into trouble. In a long programming career, I’ve seen people spend weeks trying to track down obscure memory problems. It’s usually quite easy to track down problems that cause your program to crash every 10 minutes. But once every ten days? Not so easy at all.
Of course, in modern garbage collected languages like C# and Java, memory leaks are no longer a problem – or are they? It’s certainly the case that garbage collection makes life a lot easier. In general, you don’t have to bother about freeing up memory – it’s done automatically. However, you can still get problems if you call system APIs or libraries written in another language where memory is not managed.
If you have (or think you have) a memory leak problem, then a tool to track down the source of the leak might be useful. One such tool is Deleaker. This comes with a 14 day trial period where you can use the full functionality of the tool. Deleaker helps you find and fix memory leaks in your C, C++ or Object Pascal programs developed using either Microsoft’s Visual Studio or Embarcadero’s RAD Studio/Delphi.
This is Deleaker’s own video showing integration with RAD Studio.
When installed, Deleaker can either be run from a menu item in your chosen IDE or it can be run as a standalone application so that it is available on a PC without the IDE installed. The licence allows a single user to run Deleaker on multiple PCs which is convenient if you need to use it both on your desktop computer and also on a laptop.
|Here I have docked Deleaker into the Delphi IDE. You can keep its window ‘free-floating’ if you prefer.|
We tried it out on some very simple programs with a couple of memory leaks and it worked great. At the end of the run, Deleaker will identify the leaks and indicate the source of the leak. However, it doesn’t (and can’t) tell you where you should have freed the memory. But it’s a good start and with some extra coding diagnostics, you should be able to track down memory leaks reasonably easily.
In my experience, though, simple memory leaks are not the huge problem that they are sometimes made out to be. First, from my own experience early on in my programming career seeing other programmers get in real deep trouble, I’ve been absolutely fanatical about memory allocation. Because of that I’ve never had a serious problem. The other memory problem that Deleaker can’t help with is where you have accidentally reused some freed memory: you have two pointers to the same memory address and you’ve forgotten about the second pointer when you called free on the first. These can be very tricky indeed to track down.
But where Deleaker does score is keeping track of system resources such as GDI device contexts, handles and the like. It is surprisingly easy to lose track of these because they tend to exist for a long time in the program and the effects of not freeing handles are not obvious – you don’t see memory creeping up and your program slowing down dramatically until the whole of Windows starts to seize up.
|Here Deleaker has produced a report of some leaks in a Visual Studio C project.|
At the end of the day, while you have been careful about memory allocation and resource tracking (and in my case paranoid about it) – how you do you know that you have no memory leaks? Without something like Deleaker you won’t - and here Deleaker does shine in acting as a quality check keeping track of memory and non-obvious system resources: it’s always a lot cheaper to fix bugs before releasing software and any tool such as Deleaker that helps produce bug free software is well worth the money.
For this review Dermot Hogan reviewed Deleaker for Visual Studio (Huw Collingbourne tested it with Delphi)