Skip Menu |

This queue is for tickets about the Date-Manip CPAN distribution.

Report information
The Basics
Id: 54937
Status: resolved
Priority: 0/
Queue: Date-Manip

People
Owner: sbeck [...] cpan.org
Requestors: felix.ostmann [...] thewar.de
Cc:
AdminCc:

Bug Information
Severity: Critical
Broken in: 6.07
Fixed in: (no value)



Subject: memleak
perl -MDate::Manip=ParseDate -e 'for(1..1000000) { my $a = ParseDate("2010-02-01 01:02:03"); sleep(3) if( $_ % 10000 == 0 ); }' every ParseDate use X ram and never free it. Dont have time to investigate, simple remove Date::Manip and add other working modul.
I have run the module through Devel::LeakTrace::Fast which I hope will shed some light on this matter for the module author. I think this is a shame because it would mean that the module could not be used in persistent environments.
Subject: typescript
Download typescript
application/octet-stream 979.5k

Message body not shown because it is not plain text.

I've finally been able to track down this problem. There is a memory leak in perl impacting named regexp captures (which Date::Manip uses extensively) which is causing this. I have reported the bug (perlbug #78266), but until it is resolved, I don't have an easy way to fix this. Rewriting all of the regexps in Date::Manip, while possible, is not a solution that I want to implement (I specifically switched to named captures due to the much cleaner and more secure code they allow). In the meantime, using Date::Manip 5.xx (where possible) is a workaround. A crude estimate of the leak is around 3 MB per 10000 dates parsed, so unless you're parsing hundred of thousands or millions of dates, the leak probably won't be a problem, and if you're parsing this many dates, Date::Manip may not be the right tool for you anyway.
A patch has been applied to perl which corrects this. Vulnerable versions include all releases up to: 5.10.1 5.12.4 5.14.2 5.15.5 Versions which work currently are: 5.15.6 I'm not sure if there will be a 5.12.5 or 5.14.3 release with the patch.