Re^9: Memory leak question

[BrowserUk]

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

I'm the wrong person to ask. Most of the tools I've seen suggested for this--including Devel::LeakTrace & Devel::LeakTrace::Fast--don't run on my platform, so I've evolved other, source-code based, techniques.

I've seen many references to a *nix tool: valgrind, but I've no experience of it.

If you can send me a copy of your latest code, I could have a go using my limited techniques while you research the tools?

[SBECK]

I've been using both of these... but the output is cryptic (to me at least... I suspect someone for who memory leak tracing is second nature find them more than adequate). I played just a bit with valgrind too... I may spend some additional time with it.

I'd certainly appreciate you looking at my module... but I don't expect you to. You've already given me tons of help. If you're up for it though, I've placed a copy: http://sullybeck.com/Date-Manip-6.13.tar.gz It's a little bigger than I wanted to include as an attachment.

Thanks again.

[BrowserUk]

I downloaded it, and attempted a build, but--as is typical with modules that use the insanely complicated, egotistically over-engineered, crappily buggy, Module::Build--it outputs Building Date-Manip and then sits chewing 100% cpu and does absolutely nothing.

Total insanity for a pure perl module that doesn't even need a bloody compiler. The Module::Build author should be strung up by his nether regions!

So sorry, unless you have an alternative distribution that will build on Windows, I won't be able to do anything.

At least not tonight. Maybe tomorrow I'l have a go at a manual install--but given the complexity of the thing, I'm not making any promises.

[SBECK]

I wasn't aware that Module::Build was such a problem on Windows. I do very little development on windows (basically just a small amount of debugging) and hadn't encountered that problem.

Don't waste your time doing a manual install... with over 900 timezone modules in Date::Manip, that wouldn't be a good use of your time. Instead, I have created a new bundle which uses Makefile.PL instead and put it at: http://sullybeck.com/Date-Manip-6.13a.tar.gz.

As a side note, the reason that Date::Manip currently uses Build.pl is that it gave me the flexibility to test what version of perl was running and then install either version 5 or version 6 of Date::Manip (Date::Manip 6 requires perl 5.10 or higher). I just threw away version 5 for the temporary bundle I created for you, so I didn't need that flexibility.

I was planning on changing this however. After playing with this for a few versions, I've decided that I want to simply install both versions for everyone and then have Date::Manip be a wrapper to load the appropriate version. This will mean being able to go back to providing both a Build.PL and Makefile.PL. This planned change was a bit lower on my priority list, but given your previous message, it has jumped up much higher, and I'm going to try to include that in the next release.

Thanks again.