I’m a big fan of continuous integration and I wanted to integrate memory leak checking into tests. And the I found this library:
Now I have some experience with that and I can give some info about usage of this library:
I use this library for finding memory leaks in my web service with a big amount of code. I use DUnitX and I use only Windows operating system (also in production)
Integration with DUnitX
Integration with DUnitX is really easy. You should just add five files to the project:
You should also consider that LeakCheck units are the first units in your dpr file, it’s important.
After that TDUnitXLeakCheckMemoryLeakMonitor will be automatically registered in DUnitX IoC container and you’ll get output about your memory leaks.
Sometimes, LeakCheck can crash the tests, in this case, try to clean and rebuild your project completely, it may help.
LeakCheck also can show you stack traces of your memory leaks. It looks so (part of redirected output):
To use this feature, you should:
- Enable generation of .map file for your project (very useful feature for tests!). More info here: http://docwiki.embarcadero.com/RADStudio/Tokyo/en/API_(*.map)
- Add the following units to your project (Windows only, but is also possible on other platforms):
After that, you’ll see all stack traces for your memory leaks. But, there is one big problem: this is not very performant. After each test LeakCheck loads and parses .map file completely and it is terrible for performance. I have a 31MB .map file and when I run tests with stack trace then it takes veeeeery long. But you can increase performance by rewriting MapStackTraceFormatter. IMHO, it should be patched.
I survived my first heap corruption in my life after I started using LeakCheck. But I found in LeakCheck.Configuration.inc a parameter called “UseInternalHeap”
By disabling it, LeakCheck will use standard routines for allocations and it has helped me.
You can use TLeakCheck.IgnoredLeakTypes to ignore some kinds of leaks. But, the problem is that LeakCheck doesn’t understand RegisterExpectedMemoryLeak and shows such leaks like “IdCriticalSection” for Indy, that are ignored in FastMM. Actually, I don’t know whether it’s possible to replace this procedure, but it would be useful and it will make reports more cleaner.
I didn’t find any issue tracker or contacts of the author. It’s bad.
- Use TLeakCheck.RegisterExpectedMemoryLeak in your code
- Don’t use “lazy” singletons: they will be reported by the memory manager as leaks after first call. I mean something like:
LeakCheck is very cool library and this helps you to keep your software and tests clean and detect memory leaks so early as possible.
That’s all for today :)