Postmortem Memory Profiling with Perl
Irish writes "Problems with memory, such as leaks and memory-greedy applications can cause many problems for application developers; more so for wireless applications due to the prevalence of memory-constrained devices as platforms. This article shows you how to avoid memory problems and it shows how to use Perl script to analyze memory issues for later repair. It offers three progressively more sophisticated solutions to demonstrate the concept."
But what is the big deal here?
... could be achieved in C by replacing the allocate calls with a macro that inserts the filename and line number. Alternatively, add a parameter (string/number) to the allocate function and then preprocess the source with an external tool (PERL script, for example) that puts a unique value in each call to a memory function.
We've had this kind of memory leak tracing for ages (simple C++ macro's to wrap around 'new' and 'delete' is one example)
Ok, so we're doing it externally with perl now, yay.
And by the way:
If you need to edit the source, then why use an external script in the first place?
The path I walk alone is endlessly long.
30 minutes by bike, 15 by bus.
No, it isn't. It would be ironic if Perl itself, the interpreter, was full of memory leaks and buffer overflows or if the language forced you to do your own error-prone memory management, but neither of which is the case.
Perl, the interpreter, is one of the most stable pieces of software I've ever used, virtually devoid of buffer overflows and memory leaks, and it takes care of all of the memory management for you.