Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

[perl #27206] Memory leak in continue loop

0 views
Skip to first unread message

perlbug-...@perl.org

unread,
Feb 28, 2004, 11:11:53 AM2/28/04
to bugs-bi...@netlabs.develooper.com
# New Ticket Created by perl-...@ton.iguana.be
# Please include the string: [perl #27206]
# in the subject line of all future correspondence about this issue.
# <URL: http://rt.perl.org:80/rt3/Ticket/Display.html?id=27206 >

This is a bug report for perl from perl-...@ton.iguana.be,
generated with the help of perlbug 1.34 running under perl v5.8.2.


-----------------------------------------------------------------
[Please enter your report here]

#! /usr/bin/perl -w
my @F = 1..10;
{
redo while @F;
} continue {
}

leaks many megabytes per second

[Please do not change anything below this line]
-----------------------------------------------------------------
---
Flags:
category=core
severity=low
---
Site configuration information for perl v5.8.2:

Configured by ton at Sun Jan 4 19:19:06 CET 2004.

Summary of my perl5 (revision 5.0 version 8 subversion 2) configuration:
Platform:
osname=linux, osvers=2.6.0, archname=i686-linux-64int-ld
uname='linux quasar 2.6.0 #3 thu dec 18 18:22:48 cet 2003 i686 gnulinux '
config_args=''
hint=recommended, useposix=true, d_sigaction=define
usethreads=undef use5005threads=undef useithreads=undef usemultiplicity=undef
useperlio=define d_sfio=undef uselargefiles=define usesocks=undef
use64bitint=define use64bitall=undef uselongdouble=define
usemymalloc=y, bincompat5005=undef
Compiler:
cc='cc', ccflags ='-fno-strict-aliasing -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64',
optimize='-O2 -fomit-frame-pointer',
cppflags='-fno-strict-aliasing -I/usr/local/include'
ccversion='', gccversion='3.4.0 20031231 (experimental)', gccosandvers=''
intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=12345678
d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=12
ivtype='long long', ivsize=8, nvtype='long double', nvsize=12, Off_t='off_t', lseeksize=8
alignbytes=4, prototype=define
Linker and Libraries:
ld='cc', ldflags =' -L/usr/local/lib'
libpth=/usr/local/lib /lib /usr/lib
libs=-lnsl -ldb -ldl -lm -lcrypt -lutil -lc
perllibs=-lnsl -ldl -lm -lcrypt -lutil -lc
libc=/lib/libc-2.3.2.so, so=so, useshrplib=false, libperl=libperl.a
gnulibc_version='2.3.2'
Dynamic Linking:
dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-rdynamic'
cccdlflags='-fpic', lddlflags='-shared -L/usr/local/lib'

Locally applied patches:

---
@INC for perl v5.8.2:
/usr/lib/perl5/5.8.2/i686-linux-64int-ld
/usr/lib/perl5/5.8.2
/usr/lib/perl5/site_perl/5.8.2/i686-linux-64int-ld
/usr/lib/perl5/site_perl/5.8.2
/usr/lib/perl5/site_perl
.

---
Environment for perl v5.8.2:
HOME=/home/ton
LANG (unset)
LANGUAGE (unset)
LD_LIBRARY_PATH (unset)
LOGDIR (unset)
PATH=/home/ton/bin.Linux:/home/ton/bin:/home/ton/bin.SampleSetup:/usr/local/bin:/usr/local/sbin:/usr/local/jre/bin:/home/oracle/product/9.0.1/bin:/usr/local/ar/bin:/usr/games/bin:/usr/X11R6/bin:/usr/share/bin:/usr/bin:/usr/sbin:/bin:/sbin:.
PERL_BADLANG (unset)
SHELL=/bin/bash

Rafael Garcia-Suarez

unread,
Mar 3, 2004, 5:29:25 AM3/3/04
to perl5-...@perl.org
Perl-...@Ton.Iguana.Be wrote in perl.perl5.porters :

> #! /usr/bin/perl -w
> my @F = 1..10;
> {
> redo while @F;
> } continue {
> }
>
> leaks many megabytes per second

according to valgrind, this leak is fixed in bleadperl. I don't
know whether it is in maint.

Marcus Holland-Moritz

unread,
Mar 3, 2004, 5:43:18 AM3/3/04
to Rafael Garcia-Suarez, perl5-...@perl.org

It may not be a memory "leak", but the above program is eating
up the whole memory within seconds, for whatever reason. Even
with blead and maint.

--
Thus spake the master programmer:
"When a program is being tested, it is too late to make design changes."
-- Geoffrey James, "The Tao of Programming"

Dave Mitchell

unread,
Mar 3, 2004, 5:48:19 AM3/3/04
to Rafael Garcia-Suarez, perl5-...@perl.org

Nope, it still leaks in bleed. The problem (I think) is that pp_enter is
called too often, so the save stack grows without bounds

$ ./perl -Dt /tmp/p
...
(/tmp/p:3) enter
(/tmp/p:3) nextstate
(/tmp/p:3) enter
(/tmp/p:3) padav(@F)
(/tmp/p:3) and
(/tmp/p:3) redo
(rinse and repeat)


9 <;> nextstate(main 4 p:4) v ->a
l <2> leaveloop vK/2 ->m
a <{> enterloop(next->k last->l redo->b) v ->b
- <@> lineseq vK ->l
j <@> leave vKP ->k
b <0> enter v ->c
c <;> nextstate(main 2 p:3) v ->d
i <@> leave vK* ->j
d <0> enter v ->e
- <1> null vKP/1 ->i
f <|> and(other->g) vK/1 ->i
e <0> padav[@F:1,4] s ->f
- <@> lineseq vK ->-
g <0> redo v* ->h
h <0> unstack v ->e
- <@> scope vK ->-
k <0> stub v ->l


compared with when the continue block is omitted:

(/tmp/p:3) nextstate
(/tmp/p:3) enter
(/tmp/p:3) padav(@F)
(/tmp/p:3) and
(/tmp/p:3) redo
(rinse and repeat)


9 <;> nextstate(main 3 p:3) v ->a
i <2> leaveloop vK/2 ->j
a <{> enterloop(next->i last->i redo->b) v ->b
- <@> lineseq vKP ->i
b <;> nextstate(main 2 p:3) v ->c
h <@> leave vK* ->i
c <0> enter v ->d
- <1> null vKP/1 ->h
e <|> and(other->f) vK/1 ->h
d <0> padav[@F:1,3] s ->e
- <@> lineseq vK ->-
f <0> redo v* ->g
g <0> unstack v ->d

--
This email is confidential, and now that you have read it you are legally
obliged to shoot yourself. Or shoot a lawyer, if you prefer. If you have
received this email in error, place it in its original wrapping and return
for a full refund. By opening this email, you accept that Elvis lives.

Rafael Garcia-Suarez

unread,
Mar 3, 2004, 5:48:41 AM3/3/04
to Marcus Holland-Moritz, perl5-...@perl.org
Quoting Marcus Holland-Moritz <m...@gmx.de>:
> > according to valgrind, this leak is fixed in bleadperl. I don't
> > know whether it is in maint.
>
> It may not be a memory "leak", but the above program is eating
> up the whole memory within seconds, for whatever reason. Even
> with blead and maint.

Fair enough. Feeling confused.

Dave Mitchell

unread,
Mar 3, 2004, 4:07:35 PM3/3/04
to Rafael Garcia-Suarez, perl5-...@perl.org
On Wed, Mar 03, 2004 at 10:48:19AM +0000, Dave Mitchell wrote:
> On Wed, Mar 03, 2004 at 10:29:25AM -0000, Rafael Garcia-Suarez wrote:
> > Perl-...@Ton.Iguana.Be wrote in perl.perl5.porters :
> > > #! /usr/bin/perl -w
> > > my @F = 1..10;
> > > {
> > > redo while @F;
> > > } continue {
> > > }
> > >
> > > leaks many megabytes per second
> >
> > according to valgrind, this leak is fixed in bleadperl. I don't
> > know whether it is in maint.
>
> Nope, it still leaks in bleed. The problem (I think) is that pp_enter is
> called too often, so the save stack grows without bounds

Correction: its the the tmps stack that grows without bounds.

It can be demonstrated with the even simpler code:

my @F = (1);
{
@F && redo;
}
continue {
}

The @f in scalar context pushes a mortal IV(1) onto the tmps stack;
without the continue block the instruction following the redo is a
nextstate which promptly pops the tmp off again; in the presence of the
continue block, there is an an enter before the nextstate, so tmps_floor
gets bumped up, and the nextstate doesn't release the IV(1).

The following patch fixes it by doing a FREETMPS at the end of pp_redo();
however I haven't applied it yet because I'm not sure its the best fix.
(Or even that a correct one!)

Dave.

--
To collect all the latest movies, simply place an unprotected ftp server
on the Internet, and wait for the disk to fill....

--- pp_ctl.c- Wed Mar 3 20:45:13 2004
+++ pp_ctl.c Wed Mar 3 20:45:32 2004
@@ -2115,6 +2115,7 @@ PP(pp_redo)
TOPBLOCK(cx);
oldsave = PL_scopestack[PL_scopestack_ix - 1];
LEAVE_SCOPE(oldsave);
+ FREETMPS;
return cx->blk_loop.redo_op;
}

Dave Mitchell

unread,
Mar 4, 2004, 6:55:24 PM3/4/04
to Rafael Garcia-Suarez, perl5-...@perl.org
On Wed, Mar 03, 2004 at 09:07:35PM +0000, Dave Mitchell wrote:
> The following patch fixes it by doing a FREETMPS at the end of pp_redo();
> however I haven't applied it yet because I'm not sure its the best fix.
> (Or even that a correct one!)

In the absence of any negative feedback or better ideas, I've now applied
it (along with a test) as change #22438.

--
"Emacs isn't a bad OS once you get used to it.
It just lacks a decent editor."

0 new messages