Hello xjd925z, and welcome to the Monastery!

You could also try Test::LeakTrace, or the various modules listed in the “SEE ALSO” section of its documentation.

Hope that helps,

Devel::Size might be useful, especially if you have some idea which variables/objects/data structures might be suspect.

Do you know why you've been told it's leaking? Assuming this is on a unix/linux box, can you try "top -p your_process_pid" and see if the VIRT figure grows in an unbounded way over time?

How do you debug a script that - you've been told - is causing memory leaks?

• Devel::Cycle
• Test::Memory::Cycle

Some CPAN modules that might prove useful:

• Devel::Cycle
• Test::Memory::Cycle
• Test::LeakTrace
• Devel::Leak
• Devel::Leak::Object
• Devel::LeakTrace::Fast
• Devel::Peek
• Devel::Size
• Devel::DumpSizes

Tracking down memory leaks at the C level can be done with a tool like valgrind, as discussed in Re: Valgrind, Perl, and banishing leaks.

As to when the memory is actually released back to the OS, see the answers to this question.

A very important step in this is reproducing the problem. If this is a good defect (bug) report, then it will explain in detail what the user did to cause the problem and what they did to measure the problem.

Your first step is to make what the user saw happen, happen for you on your test system. Then once you can make it happen, try to make as short a case as possible that will make the problem happen as frequently as possible and as easily as possible.

I have worked on some problem reports full-time for a week to make the problem report into something that the Developer cannot ignore...Run program A and this causes problem X, measured by metric Y. Repeatability is a key step to figuring out a solution.