Why memory leak is not reported when perl is compiled with `DEBUG_LEAKING_SCALARS`?

Question

I compile perl with DEBUG_LEAKING_SCALARS as described here

CASE 1
I follow this DOC to test memory leaking reporting:

env PERL_DESTRUCT_LEVEL=2 valgrind perl -e '@x; $x[0]=\@x'
==7216== Memcheck, a memory error detector
==7216== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al.
==7216== Using Valgrind-3.11.0 and LibVEX; rerun with -h for copyright info
==7216== Command: perl -e @x;\ $x[0]=\\@x
==7216== 
==7216== 
==7216== HEAP SUMMARY:
==7216==     in use at exit: 0 bytes in 0 blocks
==7216==   total heap usage: 1,310 allocs, 1,310 frees, 171,397 bytes allocated
==7216== 
==7216== All heap blocks were freed -- no leaks are possible
==7216== 
==7216== For counts of detected and suppressed errors, rerun with: -v
==7216== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)

Nothing is reported.

CASE 2
I even in my XS sub do this thing. Exactly:

#define PERL_NO_GET_CONTEXT
#include "EXTERN.h"
#include "perl.h"
#include "XSUB.h"

#include "XSUtils.h"
#include "ppport.h"

void
call_perl() {
    SV *sv;
    sv =  sv_2mortal( newSVpv( "XS::Utils::hello", 0 ) );

    newSViv( 323 );     //<<<< SHOULD LEAK
    printf( "Hi 3\n" );

    ENTERSCOPE;
    CALLPERL( sv , G_DISCARD|G_NOARGS );
    LEAVESCOPE;
}

MODULE = XS::Utils                    PACKAGE = XS::Utils

void
test()
    CODE:
        call_perl();

Link to the REPO

$ env PERL_DESTRUCT_LEVEL=2 valgrind perl -Iblib/arch/ -Iblib/lib -MXS::Utils -e 'XS::Utils::test()' 
==7308== Memcheck, a memory error detector
==7308== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al.
==7308== Using Valgrind-3.11.0 and LibVEX; rerun with -h for copyright info
==7308== Command: perl -Iblib/arch/ -Iblib/lib -MXS::Utils -e XS::Utils::test()
==7308== 
Hi 3
Hello
==7308== 
==7308== HEAP SUMMARY:
==7308==     in use at exit: 1,502 bytes in 5 blocks
==7308==   total heap usage: 12,876 allocs, 12,871 frees, 1,945,298 bytes allocated
==7308== 
==7308== LEAK SUMMARY:
==7308==    definitely lost: 0 bytes in 0 blocks
==7308==    indirectly lost: 0 bytes in 0 blocks
==7308==      possibly lost: 0 bytes in 0 blocks
==7308==    still reachable: 1,502 bytes in 5 blocks
==7308==         suppressed: 0 bytes in 0 blocks
==7308== Rerun with --leak-check=full to see details of leaked memory
==7308== 
==7308== For counts of detected and suppressed errors, rerun with: -v
==7308== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)

Nothing is reported too

CASE 3
I fix module Devel::LeakTrace (The FIX):

$ perl -MDevel::LeakTrace -Iblib/arch/ -Iblib/lib -MXS::Utils -e 'XS::Utils::test()' 
Hi 3
Hello

Nothing is reported too

CASE 4
I only found Test::LeakTrace do its job:

$ perl -MTest::LeakTrace::Script=-verbose -Iblib/arch/ -Iblib/lib -MXS::Utils -e 'XS::Utils::test()' 
Hi 3
Hello
leaked SCALAR(0x208e1c0) from -e line 1.
ALLOCATED at -e:1 by entersub (parent 0x0); serial 9642
SV = IV(0x208e1b0) at 0x208e1c0
  REFCNT = 1
  FLAGS = (IOK,pIOK)
  IV = 323

Why built in tool in perl report nothing about leaking?
What did I wrong? How to debug leaking memory with DEBUG_LEAKING_SCALARS tool?

You know, maybe you should just hang out in #p5p on irc.perl.org. I have the feeling the people there are a bit more versed with this stuff you're doing than we are here. :) — simbabque, Mar 11 '17 at 21:33
@simbabque .., but for a reference would be nice to know the answer too... :) :) — clt60, Mar 11 '17 at 21:41
@jm666 absolutely. It's super useful of him doing that, but he ends ups posting his own answer after a day or two every time. With a bit of context about what he's doing it could be a tech blog. :D Please continue Eugen. — simbabque, Mar 11 '17 at 21:42

score 1 · Answer 1 · edited May 23 '17 at 12:09

Actually not an answer, but from Dave Mitchell:

The main purpose of DEBUG_LEAKING_SCALARS isn't to list leaked scalars
(!!)
It's to help in tracking down things generally related to leaked scalars and refcount problems. its two main features are that it turns SV allocation from being a macro to being a function so that you can easy attach a breakpoint; and that it adds instrumentation to each SV showing where it was allocated (as displayed by Devel::Peek).

But I will not know what to debug, because I do not know that something is leaking. Like CASE from 1 to 3 described above. I was sure that:

newSViv( 323 );

Did not leak.

So DEBUG_LEAKING_SCALARS should list leaked scalars

Also I have found this comment at perl commit history:

-[ 24088] By: davem on 2005/03/28 21:38:44
- Log: expand -DDEBUG_LEAKING_SCALARS to instrument the creation of each SV

This will be very useful for this task to my mind.

This answers why the `DEBUG_LEAKING_SCALARS` doesn't list leaks (cause it's point is to make debugging leaks easier, not to identify leaks in the first place), but it makes the dubious and unexplained claim that `DEBUG_LEAKING_SCALARS` should list leaked scalars, and it doesn't explain why the tools that are designed to find leaks (`valgrind` and Devel::LeakTrace) don't find it. — ikegami, Mar 12 '17 at 06:07

Why memory leak is not reported when perl is compiled with `DEBUG_LEAKING_SCALARS`?

1 Answers1