Regular readers will know that I am passionately keen on retro-style adventure games. Not only are they great fun to play but they are also great fun to program. Don't be fooled into thinking that an adventure game is a trivial program to write, however. It isn't. It requires you to use a very broad range of programming techniques: creating class hierarchies, overriding and overloading methods, generic lists, serialization to save and load networks of mixed data types. And much more.
I've recently started a YouTube series on programming games in Java. This complements my book, 'The Little Book Of Adventure Game Programming' which uses C# as the primary language.
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.
Deleaker has a very nice integration with Visual Studio and Delphi and most of the time it works smoothly though it did crash Visual Studio on one occasion. You can also use it in standalone mode from the console – Deleaker attaches itself to the process you specify so as to perform its magic.
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.
Overall, Deleaker is a nice, simple tool that fits in well with Visual Studio and Delphi and makes tracking down memory leaks much easier. It’s not a cure-all for poor programming practice, though. If you have a badly written program, it will tell you that you have a leak and the line that allocated the memory, but it’s up to you to find out where you should have freed it.
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)
