Your message dated Fri, 6 Jun 2008 15:31:18 +0300
with message-id <[EMAIL PROTECTED]>
and subject line Re: Bug#332627: perl: Memory leak (?) and huge memory usege in
s{}{} operator.
has caused the Debian Bug report #332627,
regarding perl: Memory leak (?) and huge memory usege in s{}{} operator.
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [EMAIL PROTECTED]
immediately.)
--
332627: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=332627
Debian Bug Tracking System
Contact [EMAIL PROTECTED] with problems
--- Begin Message ---
Package: perl
Version: 5.8.4-8
Severity: normal
*** Please type your report below this line ***
Small perl program for demonstration problem:
my $nop;
print "1st:",`grep ^VmSize /proc/$$/status`;
my $s="A" x 5000000;
print "2nd:",`grep ^VmSize /proc/$$/status`;
$s =~s{(.)}{$1}gxe;
print "3th:",`grep ^VmSize /proc/$$/status`;
$s =~s{(.)}{$nop="";$1}gxe;
print "4th:",`grep ^VmSize /proc/$$/status`;
$s =~s{(.)}{$nop="";$1}gxe;
print "5th:",`grep ^VmSize /proc/$$/status`;
$s=$s.$s.$s.$s.$s.$s.$s.$s.$s.$s;
print "6th:",`grep ^VmSize /proc/$$/status`;
With strange result:
1st:VmSize: 3048 kB
2nd:VmSize: 12816 kB
3th:VmSize: 17700 kB
4th:VmSize: 342868 kB
5th:VmSize: 347752 kB
6th:VmSize: 440532 kB
1st - perl w/o big date structure in memory.
2nd - perl with "$s" and repetition_hidden_val (See:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=327611)
3nd - space enlarged by 5Mb for procesing s{(.)}{$1}gxe
4th - enlarged by 330Mb for processing 5Mb string !!!
5th - increase by 5Mb (memory reusege?)
6th - no memory reusege :-(
-- System Information:
Debian Release: 3.0
APT prefers testing
APT policy: (150, 'testing'), (40, 'unstable')
Architecture: i386 (i686)
Kernel: Linux 2.4.27-up
Locale: LANG=C, LC_CTYPE=ru_RU.koi8-r (charmap=KOI8-R)
Versions of packages perl depends on:
ii libc6 2.3.2.ds1-22 GNU C Library: Shared libraries an
ii libdb4.2 4.2.52-18 Berkeley v4.2 Database Libraries [
ii libgdbm3 1.8.3-2 GNU dbm database routines (runtime
ii perl-base 5.8.4-8 The Pathologically Eclectic Rubbis
ii perl-modules 5.8.4-8 Core Perl modules
-- no debconf information
--- End Message ---
--- Begin Message ---
Version: 5.10.0-1
On Fri, Oct 07, 2005 at 02:51:04PM +0400, Andrew Shirrayev wrote:
> Package: perl
> Version: 5.8.4-8
> Severity: normal
> my $nop;
> print "1st:",`grep ^VmSize /proc/$$/status`;
> my $s="A" x 5000000;
> print "2nd:",`grep ^VmSize /proc/$$/status`;
> $s =~s{(.)}{$1}gxe;
> print "3th:",`grep ^VmSize /proc/$$/status`;
> $s =~s{(.)}{$nop="";$1}gxe;
> print "4th:",`grep ^VmSize /proc/$$/status`;
> $s =~s{(.)}{$nop="";$1}gxe;
> print "5th:",`grep ^VmSize /proc/$$/status`;
> $s=$s.$s.$s.$s.$s.$s.$s.$s.$s.$s;
> print "6th:",`grep ^VmSize /proc/$$/status`;
> With strange result:
>
> 1st:VmSize: 3048 kB
> 2nd:VmSize: 12816 kB
> 3th:VmSize: 17700 kB
> 4th:VmSize: 342868 kB
> 5th:VmSize: 347752 kB
> 6th:VmSize: 440532 kB
>
>
> 1st - perl w/o big date structure in memory.
> 2nd - perl with "$s" and repetition_hidden_val (See:
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=327611)
> 3nd - space enlarged by 5Mb for procesing s{(.)}{$1}gxe
> 4th - enlarged by 330Mb for processing 5Mb string !!!
> 5th - increase by 5Mb (memory reusege?)
> 6th - no memory reusege :-(
The big issue here seems to be fixed with 5.10.0:
1st:VmSize: 3356 kB
2nd:VmSize: 13124 kB
3th:VmSize: 18016 kB
4th:VmSize: 22900 kB
5th:VmSize: 27784 kB
6th:VmSize: 120564 kB
I assume this is enough to consider this bug closed. The following
quotation from perldebguts.pod still applies:
Perl is a profligate wastrel when it comes to memory use. There is
a saying that to estimate memory usage of Perl, assume a reasonable
algorithm for memory allocation, multiply that estimate by 10, and
while you still may miss the mark, at least you won’t be quite so
astonished. This is not absolutely true, but may provide a good grasp
of what happens.
--
Niko Tyni [EMAIL PROTECTED]
--- End Message ---
