http://www.perlmonks.org?node_id=863622


in reply to Re^4: Memory leak question
in thread Memory leak question

does this indicate that maybe the problem isn't (directly) with Date::Manip?

You might be right.

One source of leaks is the routine _iso8601_rx(). If you modify it:

sub _iso8601_rx { return ''; ...

This doesn't leak any more:

#!/usr/bin/perl -slw use Date::Manip::Date; $date = new Date::Manip::Date; #use Devel::LeakTrace::Fast; for (1..100e6) { $date->parse("2010-02-01 01:02:03"); }

Now that routine uses an extensive given/when construct, which I've had problems with in the past. And I think I've read other bug reports alluding to memory leaks associated with that construct previously.

To confirm my suspicion, I commented out the given( $rx ) { line and closing brace, and replaced all the whens with an if/elsif/else cascade. The result was that the rate of memory leak reduced markedly. Perhaps to 1/10 of the rate.

You do have 6 other given/when constructs in the file and I strongly suspect that if you replaced those similarly with if/elsif/else cascades, your memory leaks would abate even further, if not completely.


Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
"Science is about questioning the status quo. Questioning authority".
In the absence of evidence, opinion is indistinguishable from prejudice.

Replies are listed 'Best First'.
Re^6: Memory leak question
by SBECK (Chaplain) on Oct 05, 2010 at 15:46 UTC
    WOW!!! I didn't expect you to do my debugging for me, but I really appreciate your help!

    Although I like the syntax of the given/when better... it's not a big enough deal to me to fight with memory leaks over. I'll make all of the switches and be ready to test it out later today.

    Thanks again.

      NP. I really didn't do that much. I just looked inside to see if anything rang any bells, and the given/when thing did.

      But I was unsure of my memory, so I made the changes I described to confirm them before reporting them. I didn't want to groundlessly poison the construct.

        Okay, I've now changed all given/when to if/elsif/else, and it has improved things, but it is still leaking (just not as fast).

        I'd love to reduce the leakage even further. If I understand it correctly, one source of data leaks is if the value of a variable is actually a nested structure (so it has refs in it) and I set the value to something else, the old value is destroyed (assuming a refcount of 0), but any data referenced by it may not be automatically destroyed. Is that correct? I'm fairly sure that this happens, but I'm really not looking forward to a code audit of the thousands of lines of code to track this down.

        Is there a good tool that I can use that will tell me every line number in the module where a variable was set to a new value and the old value was destroyed, but part of it hung around? Then, I could recursively destroy the old value before I created a new value (there's probably even a module to help me do this).

        This, or any other suggestions would certainly be welcome. I'm afraid that in all the time I've been programming perl, I've never tried tracking down a memory leak, and I'm mainly just stumbling around in the dark I'm afraid.