Bug 575842 - Perl leaks memory when assigning to %ENV
Summary: Perl leaks memory when assigning to %ENV
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: perl
Version: 12
Hardware: All
OS: Linux
low
medium
Target Milestone: ---
Assignee: Marcela Mašláňová
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks: 577229
TreeView+ depends on / blocked
 
Reported: 2010-03-22 14:23 UTC by Andrew Speer
Modified: 2010-09-10 17:18 UTC (History)
8 users (show)

Fixed In Version: perl-5.10.1-116.fc13
Doc Type: Bug Fix
Doc Text:
Clone Of:
: 577229 (view as bug list)
Environment:
Last Closed: 2010-08-03 01:10:28 UTC


Attachments (Terms of Use)

Description Andrew Speer 2010-03-22 14:23:58 UTC
Description of problem:

Perl leaks memory when assigning to %ENV

Version-Release number of selected component (if applicable):

5.10.0

How reproducible:

Repeatable

Steps to Reproduce:

perl -e '$ENV{foo}=1 while 1'
  
Actual results:

Memory leak until process teminated.

Expected results:

No memory leak.

Additional info:

This bug causes problems in long running processes such as FastCGI requests that use the Perl FCGI module - which uses %ENV as the repository for request information by default.

Each request causes FCGI to use more memory until the FastCGI application terminates due to excessive memory consumption.

Other long running processes which update %ENV will be affected also.

This bug was reported to the Perl bugtracker:

http://rt.perl.org/rt3/Ticket/Display.html?id=73672

where it was closed immediately as an interaction with the OS, namely use of the leaky putenv() call in the standard C library.

The Perl RT resolver stated that the leak is caused by compilation of Perl with the:

PERL_USE_SAFE_PUTENV

ccflag. Any reson this flag can't be omitted from the Fedora 12 perl build as perl the perl RT suggestion ?

Comment 1 Marcela Mašláňová 2010-03-22 14:50:56 UTC
Thank you for report with great explanation from upstream. I'll check and test it in different releases. I believe usually it's a good thing to use system libraries, but probably not in this case.

Comment 2 Marcela Mašláňová 2010-03-24 14:53:54 UTC
I've tested this behaviour without PERL_USE_SAFE_PUTENV. It works fine, so in next updates, perl won't be using system putenv anymore.

Comment 3 Chris Weyl 2010-03-26 05:20:27 UTC
Any reason we can't build and push now?  F-13 is divergent from F-12, so we don't have a problem there, and I'm sure Andrew would love to give us feedback while it's in updates-testing :)

Comment 4 Marcela Mašláňová 2010-03-26 07:30:04 UTC
I was working on different issues and patches. I'd like to push more fixes at once if you don't mind.

Comment 5 Chris Weyl 2010-03-27 18:14:03 UTC
No problem -- Just a little well-intentioned motivational querying :)

Comment 6 Marcela Mašláňová 2010-04-06 14:29:13 UTC
Fixed in rawhide for the meantime.

Comment 7 Marcela Mašláňová 2010-07-15 11:14:25 UTC
This was fixed also in F-13 with perl-5.10.1-114

Comment 8 hkoba 2010-07-23 03:50:40 UTC
Hello,

Is this really fixed?

Today I examined perl-5.10.1-114.fc13.x86_64 in F-13
and observed apparently memory usage still grows constantly in simple script.

Following simple script can show the memleak.
Please verify the package, and if you see memleaks too,
reopen this ticket please.

# Note. %ENV leakage is serious problem for FastCGI. It is very important.

=========================================
#!/usr/bin/perl -w
use strict;

for (my $i = 1; 1; $i++) {
  do {
    local %ENV = %ENV; # <==== this is the leak !
    $ENV{HOME} = "/tmp";
  };
  print " --->> $i iterations --- mem used --->> ", memsize($$), "\n"
    unless $i % 10000;
}

sub memsize {
  my ($pid) = @_;
  open my $fh, '<', "/proc/$pid/status" or die $!;
  local $_;
  while (<$fh>) {
    chomp;
    return $1 if /^VmRSS:\s+(\d+)\D+$/;
  }
}

# borrowed & modified from:
# http://www.issociate.de/board/post/474595/Memory_leak_in_Perl_5.10_on_Solaris_10_with__ENV.html

Comment 9 Marcela Mašláňová 2010-07-23 08:40:52 UTC
I looked into Changelog, where are mentioned bugs related to PUTENV. 
https://bugzilla.redhat.com/show_bug.cgi?id=508496
https://bugzilla.redhat.com/show_bug.cgi?id=453646
https://rt.cpan.org/Public/Bug/Display.html?id=37194

I forgot remove PERL_USE_SAFE_PUTENV from this branch.

Comment 10 Fedora Update System 2010-07-23 13:44:33 UTC
perl-5.10.1-116.fc13 has been submitted as an update for Fedora 13.
http://admin.fedoraproject.org/updates/perl-5.10.1-116.fc13

Comment 11 hkoba 2010-07-26 07:27:54 UTC
Thank you for your quick update!

Your perl-5.10.1-116.fc13.x86_64.rpm from koji has no more memleak for me
with above script (and other fastcgi scripts). Thank you:-)

# Note: When I installed the pkg, I got gpg error and I used --nogpgcheck 
# to avoid it. I don't know this is normal or not.

Comment 12 Marcela Mašláňová 2010-07-26 08:38:59 UTC
Just FYI the correct upstream ticket was: http://rt.perl.org/rt3//Public/Bug/Display.html?id=73672

Comment 13 Marcela Mašláňová 2010-07-26 09:08:58 UTC
(In reply to comment #11)
> Thank you for your quick update!
> 
> Your perl-5.10.1-116.fc13.x86_64.rpm from koji has no more memleak for me
> with above script (and other fastcgi scripts). Thank you:-)
> 
> # Note: When I installed the pkg, I got gpg error and I used --nogpgcheck 
> # to avoid it. I don't know this is normal or not.    

Koji builds are not signed. There are signed after push on mirror.

Comment 14 Fedora Update System 2010-07-27 02:47:28 UTC
perl-5.10.1-116.fc13 has been pushed to the Fedora 13 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update perl'.  You can provide feedback for this update here: http://admin.fedoraproject.org/updates/perl-5.10.1-116.fc13

Comment 15 Fedora Update System 2010-08-03 01:10:22 UTC
perl-5.10.1-116.fc13 has been pushed to the Fedora 13 stable repository.  If problems still persist, please make note of it in this bug report.


Note You need to log in before you can comment on or make changes to this bug.