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?

Answer 1

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.