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.

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

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 '';
...
[download]

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");
}
[download]

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.

RIP an inspiration; A true Folk's Guy