Memory Leaks

[robrwo]

The following code:

use Test::More;
use Test::LeakTrace;

no_leaks_ok {
  pass 'test';
};
done_testing;

returns the following output:

#     Elt "reason" HASH = 0xaf846532
#     SV = PV(0x9184a88) at 0x918a9a8
#       REFCNT = 1
#       FLAGS = (POK,pPOK)
#       PV = 0x9058890 ""\0
#       CUR = 0
#       LEN = 12
#     Elt "type" HASH = 0xf82567cb
#     SV = PV(0x9184fd8) at 0x904f5f0
#       REFCNT = 1
#       FLAGS = (POK,pPOK)
#       PV = 0x90f58f0 ""\0
#       CUR = 0
#       LEN = 12
#     Elt "actual_ok" HASH = 0x885534ad
#     SV = PVNV(0x9171348) at 0x9198328
#       REFCNT = 1
#       FLAGS = (IOK,pIOK)
#       IV = 1
#       NV = 0
#       PV = 0
# leaked REF(0x9198288) from /home/staff/rrwo/.plenv/versions/5.18.1/lib/perl5/site_perl/5.18.1/Test/Builder.pm line 873.
#  872:
#  873:    $self->{Test_Results}[ $self->{Curr_Test} - 1 ] = $result;
#  874:    $out .= "\n";
# SV = IV(0x9198284) at 0x9198288
#   REFCNT = 1
#   FLAGS = (ROK)
#   RV = 0x91982b8
#     SV = PVHV(0x903ae68) at 0x91982b8
#       REFCNT = 1
#       FLAGS = (SHAREKEYS)
#       ARRAY = 0x9054ae8  (0:4, 1:3, 2:1)
#       hash quality = 107.1%
#       KEYS = 5
#       FILL = 4
#       MAX = 7
#         Elt "ok" HASH = 0x734d90f0
#         SV = IV(0x918a9e4) at 0x918a9e8
#           REFCNT = 1
#           FLAGS = (IOK,pIOK)
#           IV = 1
#         Elt "reason" HASH = 0xaf846532
#         SV = PV(0x9184a88) at 0x918a9a8
#           REFCNT = 1
#           FLAGS = (POK,pPOK)
#           PV = 0x9058890 ""\0
#           CUR = 0
#           LEN = 12
#         Elt "type" HASH = 0xf82567cb
#         SV = PV(0x9184fd8) at 0x904f5f0
#           REFCNT = 1
#           FLAGS = (POK,pPOK)
#           PV = 0x90f58f0 ""\0
#           CUR = 0
#           LEN = 12
# Looks like you failed 1 test of 5.
Dubious, test returned 1 (wstat 256, 0x100)
Failed 1/5 subtests 

Test Summary Report
-------------------
leak-trace-1.t (Wstat: 256 Tests: 5 Failed: 1)
  Failed test:  3
  Non-zero exit status: 1
Files=1, Tests=5,  0 wallclock secs ( 0.03 usr  0.01 sys +  0.03 cusr  0.01 csys =  0.08 CPU)
Result: FAIL

[robrwo]

This is with version 1.001009. I've not checked other versions.

[exodist]

I will check against the latest master, if there are no leaks in master I will move this to the backlog, and close it when the new stuff is released.

The variable in question is shared for threads, so that may have something to do with it. Master does not use shared variables anymore. But I am getting ahead of myself.

[robrwo]

Test::LeakTrace complained about state variables in some modules that I am working on, but I've not been able to isolate a simple test case to submit as a bug for that. But I did find changing the "state" vars to global "my" vars fixed complaints about those particular variables. (It wasn't ideal, so I've stopped using it on a project.)

[karenetheridge]

If it's an easy fix for 1.001009, I think it's worth doing another stable release to fix it.

[exodist]

I would happily accept any patches that fix this. I am not sure when I am going to have a chance to dig into it myself. I will do so as soon as I can make the time.

[exodist]

This test also fails on master, but with different/more leaks.

[exodist]

oh, I think I know the issue in both cases. And it cannot be fixed.

Test::Builder (old and new) stores all results in an internal structure for later inspection. That is what is leaking in the old version. In the new version we get the same leak, but it results in more objects leaked. However the legacy behavior is deprecated and can be turned off (is on by default) in the new stuff.

Test::Stream->shared->set_use_legacy(0);

When that is used before the test runs there are no leaks on the new stuff. There is no such toggle for the old stuff. Disabling the behavior will make anything that uses Test::Tester fail to run.

I have not yet looked at the leak check module in question, I will do so to see if I can find why this is considered a leak.

[exodist]

Leaked SVs are SVs which are not released after the end of the scope they have been created. These SVs include global variables and internal caches. For example, if you call a method in a tracing block, perl might prepare a cache for the method. Thus, to trace true leaks, no_leaks_ok() and leaks_cmp_ok() executes a block more than once.

That is from the module. That defines leaks as any variables created in the scope that last past the scope. It is run multiple times to filter out globals and such.. but since the block produces results each time, and stores them, it will always appear to have a leak. This is not actually a leak, it is a defined, expected, and necessary behavior.

[exodist]

If someone can confirm my findings I will go ahead and close the ticket.

[exodist]

talked in #toolchain, there is not anything we can do for this right now.