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

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.

Replies are listed 'Best First'.
Re^9: Memory leak question
by BrowserUk (Patriarch) on Oct 05, 2010 at 19:54 UTC
    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?

    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]
      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.
[reply]

        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.

        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]
[d/l]

In Section Seekers of Perl Wisdom