Does Perl v5.10.1 have memory leaks or how to interpret valgrind

Question

I have a script that has memory leaks. I believe this is so because after I perform undef on my nested objects, the amount of memory in script is unchanged. I have used Devel::Cycle to locate any cyclical references and I have turned those cyclical references into weak references with Scalar::Util. The problem still remains.

Now I am trying to use Valgrind to solve the issue. As a first start with valgrind, I tested things out a perl hello world program:

#! /usr/bin/perl

use strict;
use warnings;

print "Hello world!\n";

Here was the valgrind output 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 does not equal the number of frees you have a memory leak.

Since all I'm doing is printing hello world, I'm forced to ask the question, does the Perl interpreter itself, here v5.10.1, have at least its own memory leak or am I interpreting things all wrong?

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

ADDENDUM

I see in Perl 5.12.0 delta, the following:

A weak reference to a hash would leak. This was affecting DBI [RT #56908].

This may ultimately apply to my complete perl script, and not this hello world program, but it's leading me to think that I should go through the pain of installing the latest version of perl as non-root.

ADDENDUM2

I installed activestate perl 5.16.3, and the problem, and also my actual script's problems, still remains.

I suspect that in the case of this hello world program, I must be using/interpreting valgrind improperly but I don't understand where yet.

UPDATE1 Daxim's answer does make a difference. When I introduce the following line in my perl script:

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

Then the valgrind output is:

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

Which is a substantial difference. My own memory leak problems with my script remain but at least this hello world program now seems sensible to valgrind.

This whole thing though begs the question, what is the point of stopping hard cyclical references with Scalar::Util if no memory is freed until the program exits, baring the use of this somewhat esoteric Perl::Destruct::Level module???

Answer 1

The leak is intentional. vincent in #p5p comments:

Allocated memory isn't actually released unless PERL_DESTRUCT_LEVEL is set because it's faster to let the operating system handle this. PERL_DESTRUCT_LEVEL is only available for debugging builds or by using Perl::Destruct::Level from perl.