in reply to Memory leak question

Reading between the lines of Devel::LeakTrace::Fast's description,

At END time Devel::LeakTrace::Fast identifies any remaining variables, and reports on the lines in which the came into existence.

Doesn't the fact that %Dates is a global: use vars qw(%Dates %LastRule);, mean that it won't be cleaned up automatically before END time, and is therefore designated "a leak"?

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.
RIP an inspiration; A true Folk's Guy

Replies are listed 'Best First'.
Re^2: Memory leak question
by SBECK (Chaplain) on Oct 04, 2010 at 20:01 UTC
    That was rather dumb of me...

    I'm sure you're right. Unfortunately, this just means I have to dig deeper (and probably learn to use the tools better), because Date::Manip DOES have a memory leak, I just haven't correctly identified it yet.
[reply]

      I sympathise. Tracking down leaks is a pain.

      One possibility to make your life easier, would be to add END blocks in those of your modules that use globals, to undef them.

      That should ensure that they've been cleaned up before the END block in D::L::F runs, and (perhaps) prevent a bunch of false positives and allow you to concentrate on what is left.

      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.
[reply]
        Thanks for an extremely useful suggestion. I have done this and a lot of the extra results are gone. However, there is still a memory leak. However, now I'm not sure whether it's Date::Manip, or perl.

        If I replace the parse in the script above with: 
           for (1..100) {
      $date->parse("2010-02-01 01:02:03");
   }
        I get the following output: 
           leaked SV(0x0x1300100) from /home/sulbeck/local/lib/perl5/5.10.1/Date/Manip/TZ/amnew_00.pm line 44
   leaked RV(0x0x1250200) from /home/sulbeck/local/lib/perl5/5.10.1/Date/Manip/TZ/amnew_00.pm line 44
   leaked SV(0x0x12d0300) from /home/sulbeck/local/lib/perl5/5.10.1/Date/Manip/Date.pm line 1115
   leaked SV(0x0x1310200) from /home/sulbeck/local/lib/perl5/5.10.1/Date/Manip/TZ/amnew_00.pm line 44
   leaked RV(0x0x12d0000) from /home/sulbeck/local/lib/perl5/5.10.1/Date/Manip/TZ.pm line 163
   leaked SV(0x0x1320300) from /home/sulbeck/local/lib/perl5/5.10.1/Date/Manip/TZ/amnew_00.pm line 44
   leaked SV(0x0x12a0100) from /home/sulbeck/local/lib/perl5/5.10.1/Date/Manip/Date.pm line 1115
   leaked SV(0x0x12e0100) from /home/sulbeck/local/lib/perl5/5.10.1/Date/Manip/TZ/amnew_00.pm line 44
   leaked SV(0x0x1320000) from /home/sulbeck/local/lib/perl5/5.10.1/Date/Manip/TZ/amnew_00.pm line 44
   leaked SV(0x0x12f0100) from /home/sulbeck/local/lib/perl5/5.10.1/Date/Manip/TZ/amnew_00.pm line 44
        So, even though I've got a couple leaks, it's not leaking at every iteration. It appears that there are a couple of 'one-time-only' leakes, and I'd be willing to ignore them if I can't resolve them in a reasonable amout of time.

        Unfortunately, if I just repeatedly parse the same date (i.e. do 1000000 iterations instead of 100) and monitor the size of the perl executable while it is running, it keeps growing.

        Since running for 100 iterations shows only the 10 "leaks" above, but running over many iterations shows the executable continually growing, does this indicate that maybe the problem isn't (directly) with Date::Manip? Or is this just wishful thinking?

        Thanks
[reply]

In Section Seekers of Perl Wisdom