Follow Slashdot blog updates by subscribing to our blog RSS feed

 



Forgot your password?
typodupeerror
×
Perl Programming

Postmortem Memory Profiling with Perl 11

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."
This discussion has been archived. No new comments can be posted.

Postmortem Memory Profiling with Perl

Comments Filter:
  • by dk.r*nger ( 460754 ) on Friday December 19, 2003 @10:30AM (#7764349)
    When you die, the coroner can now attach a Perl program to your brain and find out what you were thinking.

    CSI is going to be very boring now.
  • Using Perl to fix memory problems.
    • 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.

      • 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.

        I agree that the interpreter is very stable and has very few problems. I like Perl quite a

  • Excuse me.. (Score:4, Insightful)

    by MooCows ( 718367 ) on Friday December 19, 2003 @11:42AM (#7765270)
    But what is the big deal here?
    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:
    ... 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.

    If you need to edit the source, then why use an external script in the first place?
  • by isj ( 453011 ) on Friday December 19, 2003 @12:29PM (#7765947) Homepage
    The author has reinvented the wheel. Any debug heap that provides a trace can do this, so this is basically an old hat.
    http://www.cbmamiga.demon.co.uk/mpatrol/mpat rol_83 .html provides a very good list of resources for debug heaps.

You know you've landed gear-up when it takes full power to taxi.

Working...