Skip Menu |

This queue is for tickets about the Env-C CPAN distribution.

Report information
The Basics
Id: 49872
Status: resolved
Priority: 0/
Queue: Env-C

People
Owner: Nobody in particular
Requestors: Hartmut.Vogler [...] t-systems.com
Cc:
AdminCc:

Bug Information
Severity: (no value)
Broken in: 0.08
Fixed in: (no value)



Subject: Memory leak in version 0.8
If you use Env::C in the following constellation, you will get a continues growing memory usage: <!-------------------------------------------> #!/usr/bin/perl sub BEGIN { eval('use Env::C;'); eval('Env::C::setenv("TZ","GMT",1);'); } for(my $cc=0;$cc<100;$cc++){ for(my $c=0;$c<1000;$c++){ $ENV{TZ}="GMT"; $ENV{TZ}=""; } printf("Check loop $cc\n"); sleep(1); } <!-------------------------------------------> The problem seems to be only happen, if you use the Env::C as eval in the BEGIN block.
I am able to reproduce this without the eval at all, with simply: use Env::C; Env::C::setenv("TZ","GMT"); for (1..300) { for (1..1000) { $ENV{TZ} = 'GMT'; $ENV{TZ} = ''; } system "ps hu $$"; } RSS grows continually. Removing the Env::C::setenv() call results in unchanging RSS. No idea why...
From: Dean West
On Sun Dec 02 16:17:38 2012, MSCHOUT wrote: Show quoted text
> RSS grows continually. Removing the Env::C::setenv() call results in > unchanging RSS. No idea why...
At least on Linux this is caused by PL_use_safe_putenv = 1, which is executed in Env::C::setenv(). I.e. it tells Perl to use system's putenv() instead of Perl's own implementation. So any operation on %ENV after Env::C::setenv() call leaks memory. Generally it is not a good idea to change PL_use_safe_putenv from within Perl modules as it has global effect.
Fixed in v0.10, which was just released to CPAN
There are still some unresolved issues related to this ticket. Removing PL_use_safe_putenv causes test failures on FreeBSD due to segmentation fault (sig 11) under some circumstances when t/smoke.t exits. strangely, this does not always happen. One way to make it happen is to run the test from gnu make, using a makefile that exports some environment variables. Further investigation required.
Tested this using various perls on FreeBSD 10/amd64, it seems that using PL_use_safe_putenv solves the signal 11 issue, at the expense of using the leaky system putenv(). I am unable to reproduce the problem at all, using perl 5.20.0 Bisecting perl between v5.18.0 and v5.20.0, I find the first commit that is immune to this problem is: 411e93c Upgrade Test-Simple from version 0.98 to 0.99 Which does in fact avoid the problem in the tree AT THAT POINT IN TIME. Rolling back a build of 411e93c to Test::Simple v0.98 does in fact signal 11 out of the test suite. But, rolling back Test::Simple in 5.20.0 does not trigger the signal 11's, so it appears that furture bisection, between this point and v5.20.0, with a rolled back Test::Simple to v0.98 is needed to pinpoint where this problem goes away.
Further bisection, using Test::Simple 0.98 reveals that the first commit that is immune is: commit 1a8bdda9d755b989a595e71b28eba150ebaae663 Author: Father Chrysostomos <sprout@cpan.org> Date: Thu Oct 24 12:46:52 2013 -0700 rv2hv does not use its TARG rv2hv has had a TARG since perl 5.000, but it has not used it since hv_scalar was added in perl-5.8.0-3008-ga3bcc51. This commit removes it, saving a tiny bit of space in the pad. :040000 040000 6613eaf991854887817425bfa15e3115b8406c1f da3628c881b65dad514d5742cccdd4400b450400 M ext :100644 100644 07706461217a304aa10a951f3675b37e0e749f49 44067824b292791c08a512121c520d4a61235fda M opcode.h :100644 100644 11553285b1527207bb8e4b8d61cfa7c94e933def 3bbc4aaabf136ea31d8162f09c2977835cde2a45 M pp_hot.c :040000 040000 71d1e7caa075d1cdfecbf5c7b77e5cc78713b1af 5cfb15246330f733bc96ebddb25476b3b10385a7 M regen
Migrated to github issues https://github.com/mschout/env-c/issues/10 -- Regards, Michael Schout