Skip Menu |

This queue is for tickets about the Test-MemoryGrowth CPAN distribution.

Report information
The Basics
Id: 110692
Status: open
Priority: 0/
Queue: Test-MemoryGrowth
People
Owner: Nobody in particular
Requestors: SREZIC [...] cpan.org
Cc:
AdminCc:
Bug Information
Severity: (no value)
Broken in: 0.02
Fixed in: (no value)

History Show all quoted text
  Mon Dec 28 04:36:33 2015 SREZIC [...] cpan.org - Ticket created
Subject: Memory growth seen with perl 5.23.6
The t/01leak.t test fails with perl 5.23.6: # Failed test 'no_growth push fails' # at t/01leak.t line 23. # STDOUT is: # ok 1 - push does not grow # # not: # not ok 1 - push does not grow # # as expected # STDERR is: # # not: # /#\s+Failed\ test.*?\n?.*?at\ t\/01leak\.t line 22.*\n?/ # (?^:^# Lost \d+ bytes of memory over \d+ calls, average of \d+\.\d\d per call\n)(?^:^# Writing heap dump to \S+\n) # as expected t/01leak.t .... Failed 1/2 subtests The test did not fail with perl 5.23.5 and earlier. It would be good to check this out to make sure that there's no memory leak in perl itself.
  Mon Dec 28 09:10:50 2015 ANDK [...] cpan.org - Correspondence added
BBC crossreference with bisect result: https://rt.perl.org/rt3/Ticket/Display.html?id=127054
  Mon Dec 28 09:10:50 2015 The RT System itself - Status changed from 'new' to 'open'
  Fri Mar 18 11:41:21 2016 leonerd-cpan [...] leonerd.org.uk - Correspondence added
Unable to reproduce this locally on Linux/amd64 on perl 5.23.8. Might it have been a temporary issue on .6 that has now gone? -- Paul Evans
  Sat Mar 19 03:18:59 2016 SREZIC [...] cpan.org - Correspondence added
On 2016-03-18 11:41:21, PEVANS wrote: Show quoted text
> Unable to reproduce this locally on Linux/amd64 on perl 5.23.8. > > Might it have been a temporary issue on .6 that has now gone?
I cannot reproduce it anymore with 5.23.8 on my systems. But Andreas still can: http://matrix.cpantesters.org/?dist=Test-MemoryGrowth%200.02;os=linux;perl=5.23.8;reports=1 What's also interesting: with perl 5.23.7, where I can reproduce the problem, the test fails only if I run it with "Build test" or "prove", but not directly with "perl -Mblib t/01leak.t". And another thing: actually what happens in the failing tests is that the expected memory leak does _not_ happen. So at least there's no perl problem. I can imagine that for certain memory allocation patterns it may happen that the process has plenty of free memory available, but this free memory cannot be given back to the operating system, and therefore VmSize stays high. The 'push @arr, "hello"' calls now manage to re-use this free memory, so no_growth() does not fail here. On the perl 5.23.7 I managed to get a pass by increasing the number of calls from the default 10_000 to 20_000. So maybe this could be a viable workaround.
  Sat Mar 19 03:19:22 2016 SREZIC [...] cpan.org - Subject changed from 'Memory growth seen with perl 5.23.6' to '*No* memory growth seen with perl 5.23.6 .. 5.23.8'