Perl v5.10.1 has a memory leak or how to interpret valgrind

Question

I have a script that has memory leaks. I believe this is because after executing undef on my nested objects, the amount of memory in the script does not change. I used Devel :: Cycle to find any circular links, and I turned these circular links into weak links with Scalar::Util . The problem still remains.

Now I'm trying to use Valgrind to solve the problem. As a first run with valgrind, I checked things in the world program perl hello:

 #! /usr/bin/perl use strict; use warnings; print "Hello world!\n"; 

Here was the output of valgrind when running valgrind --trace-children=yes perl ./hello_world.pl :

 ==12823== HEAP SUMMARY: ==12823== in use at exit: 290,774 bytes in 2,372 blocks ==12823== total heap usage: 5,159 allocs, 2,787 frees, 478,873 bytes allocated ==12823== ==12823== LEAK SUMMARY: ==12823== definitely lost: 13,981 bytes in 18 blocks ==12823== indirectly lost: 276,793 bytes in 2,354 blocks ==12823== possibly lost: 0 bytes in 0 blocks ==12823== still reachable: 0 bytes in 0 blocks ==12823== suppressed: 0 bytes in 0 blocks ==12823== Rerun with --leak-check=full to see details of leaked memory ==12823== ==12823== For counts of detected and suppressed errors, rerun with: -v ==12823== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 6 from 6) 

My understanding, from here , is that when the number of allocs not equal to the number of frees , you have a memory leak.

Since all I do is print hello world, I have to ask the question, does the Perl interpreter itself, here v5.10.1, have at least its own memory leak or am I interpreting everything wrong?

I would like to understand this before tackling my actual perl script.

ADDITION

I see the following in Perl 5.12.0 delta :

Weak reference to a hash leak. This affected the DBI [RT # 56908].

This may eventually apply to my full version of perl script and not to this hello world program, but it makes me think that I need to go through installing the latest version of perl as non-root.

ADDENDUM2

I installed activestate perl 5.16.3 and the problem as well as my actual script problems still remain.

I suspect that in the case of this welcoming world program, I should misuse / interpret valgrind, but I don't understand yet.

Update1 Daxim’s answer really matters. When I enter the following line into my perl script:

 use Perl::Destruct::Level level => 1; 

Then the output of valgrind:

 ==29719== HEAP SUMMARY: ==29719== in use at exit: 1,617 bytes in 6 blocks ==29719== total heap usage: 6,499 allocs, 6,493 frees, 585,389 bytes allocated ==29719== ==29719== LEAK SUMMARY: ==29719== definitely lost: 0 bytes in 0 blocks ==29719== indirectly lost: 0 bytes in 0 blocks ==29719== possibly lost: 0 bytes in 0 blocks ==29719== still reachable: 1,617 bytes in 6 blocks ==29719== suppressed: 0 bytes in 0 blocks ==29719== Rerun with --leak-check=full to see details of leaked memory ==29719== ==29719== For counts of detected and suppressed errors, rerun with: -v ==29719== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 6 from 6) 

This is a significant difference. My own memory leak problems with my script remain, but at least this welcome global program now seems reasonable to valgrind.

This whole thing, although it asks the question, what is the point of stopping hard circular links from Scalar::Util if memory is not freed before the program exits, prohibiting the use of this somewhat esoteric module Perl::Destruct::Level ???

Answer 1

Leak intentionally. vincent's # p5p comments:

The allocated memory is not actually released unless PERL_DESTRUCT_LEVEL is set, because it allows the operating system to handle this faster. PERL_DESTRUCT_LEVEL is available only for debugging collections or using Perl :: Destruct :: Level from perl.

Answer 2

As I understand it (and please correct me if I am mistaken, I did not read the code, and the documentation seems rather meager), the fact is that in a typical Perl program there are many that will be highlighted, but which will not be released until the end of the program . This includes things like global variables, but also, for example, the compiled program code itself.

Now, perl can free the memory used for all this when the program finishes, but it turns out that there is usually not much point, since the OS will do it anyway. The only exception is when something like valgrind is looking for if there is any free memory at the end of the program and it is assumed that any such memory should be leaked.

So, basically, perl is usually lazy and will not be bothered by freeing up memory when it finds out that it is about to exit and let the OS take care of it. Setting PERL_DESTRUCT_LEVEL tells perl to clear this memory anyway, just to show tools like valgrind that it hasn't actually leaked.

In any case, none of this, AFAIK, affects memory management during program execution. If you reduce the number of reference samples to zero while the program is running (for example, if you allow the variable to go out of scope or directly rewrite the last link), it will be freed, regardless of PERL_DESTRUCT_LEVEL.

However, note that this usually frees up memory only for perl to be reused - besides some rare cases like explicit mmap (), it is pretty unusual for any program running on a modern OS with virtual memory to actually release memory pages back to the OS during her work.