Routinely Check for Memory Leaks |
 |
 |
 |
| Written by Graham Stoney | |||
|
If you're using one of the many languages that don't do garbage collection for you, but require manual memory allocation and freeing, and you haven't tried using a leak-detecting memory allocator yet, I can pretty much guarantee that you've got memory leaks that you don't yet know about. Often this means there are logic errors in your application too; memory doesn't just leak for no reason. The debug version of your application (the one with all the assertions enabled) should include a bounds and leak checking memory allocator, which you should run with your regression tests. Memory overrun errors are notoriously difficult to find when you are looking at them, but will often be caught easily with a bounds checking allocator; albeit while you're probably looking for something else. It's not enough just to check for memory overruns and leaks at product release time; you want a leak-detecting allocator built into your debug version so they get caught on every test run. Social Bookmark this page:         
|