Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Accessing %+ with named capture buffers causes memory leaks #9705

Closed
p5pRT opened this issue Apr 11, 2009 · 6 comments
Closed

Accessing %+ with named capture buffers causes memory leaks #9705

p5pRT opened this issue Apr 11, 2009 · 6 comments

Comments

@p5pRT
Copy link

p5pRT commented Apr 11, 2009

Migrated from rt.perl.org#64646 (status was 'resolved')

Searchable as RT64646$

@p5pRT
Copy link
Author

p5pRT commented Apr 11, 2009

From derf@sievert.tabularazor.org

This is a bug report for perl from f83a0a@​derf.homelinux.org,
generated with the help of perlbug 1.36 running under perl 5.10.0.


Apparently, accessing %+ after using named capture buffers causes memory leaks.
I tested the following snippet on various systems,
it consumes 200-400MB of memory.

-- snip --
#!/usr/bin/env perl
# use strict/warnings/5.010 do not affect this
use strict;
use warnings;
use 5.010;
my @​trash;

print "PID​: $$\n";
print "Doing stuff...\n";

for(my $i = 0; $i < 900000; $i++) {
  "foo bar quux spam ham eggs" =~ /^(?<foo>\w+) (?<bar>\w+) (?<quux>\w+) (?<spam>\w+) (?<ham>\w+) (?<eggs>\w+)$/;
  # the memory leak does not occur when %+ is not used
  # (not related to slicing, though)
  @​trash = @​+{'foo', 'bar', 'quux', 'spam', 'ham', 'eggs'};
}

print "done\n";
print "memory usage should be somewhere around 200M now, mind checking?\n";
print "(you can kill me afterwards)\n";

sleep();



Flags​:
  category=core
  severity=high


Site configuration information for perl 5.10.0​:

Configured by Debian Project at Thu Jan 1 12​:43​:38 UTC 2009.

Summary of my perl5 (revision 5 version 10 subversion 0) configuration​:
  Platform​:
  osname=linux, osvers=2.6.26-1-686, archname=i486-linux-gnu-thread-multi
  uname='linux rebekka 2.6.26-1-686 #1 smp mon dec 15 18​:15​:07 utc 2008 i686 gnulinux '
  config_args='-Dusethreads -Duselargefiles -Dccflags=-DDEBIAN -Dcccdlflags=-fPIC -Darchname=i486-linux-gnu -Dprefix=/usr -Dprivlib=/usr/share/perl/5.10 -Darchlib=/usr/lib/perl/5.10 -Dvendorprefix=/usr -Dvendorlib=/usr/share/perl5 -Dvendorarch=/usr/lib/perl5 -Dsiteprefix=/usr/local -Dsitelib=/usr/local/share/perl/5.10.0 -Dsitearch=/usr/local/lib/perl/5.10.0 -Dman1dir=/usr/share/man/man1 -Dman3dir=/usr/share/man/man3 -Dsiteman1dir=/usr/local/man/man1 -Dsiteman3dir=/usr/local/man/man3 -Dman1ext=1 -Dman3ext=3perl -Dpager=/usr/bin/sensible-pager -Uafs -Ud_csh -Ud_ualarm -Uusesfio -Uusenm -DDEBUGGING=-g -Doptimize=-O2 -Duseshrplib -Dlibperl=libperl.so.5.10.0 -Dd_dosuid -des'
  hint=recommended, useposix=true, d_sigaction=define
  useithreads=define, usemultiplicity=define
  useperlio=define, d_sfio=undef, uselargefiles=define, usesocks=undef
  use64bitint=undef, use64bitall=undef, uselongdouble=undef
  usemymalloc=n, bincompat5005=undef
  Compiler​:
  cc='cc', ccflags ='-D_REENTRANT -D_GNU_SOURCE -DDEBIAN -fno-strict-aliasing -pipe -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64',
  optimize='-O2 -g',
  cppflags='-D_REENTRANT -D_GNU_SOURCE -DDEBIAN -fno-strict-aliasing -pipe -I/usr/local/include'
  ccversion='', gccversion='4.3.2', gccosandvers=''
  intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=1234
  d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=12
  ivtype='long', ivsize=4, nvtype='double', nvsize=8, 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 /usr/lib64
  libs=-lgdbm -lgdbm_compat -ldb -ldl -lm -lpthread -lc -lcrypt
  perllibs=-ldl -lm -lpthread -lc -lcrypt
  libc=/lib/libc-2.7.so, so=so, useshrplib=true, libperl=libperl.so.5.10.0
  gnulibc_version='2.7'
  Dynamic Linking​:
  dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-Wl,-E'
  cccdlflags='-fPIC', lddlflags='-shared -O2 -g -L/usr/local/lib'

Locally applied patches​:
 


@​INC for perl 5.10.0​:
  /etc/perl
  /usr/local/lib/perl/5.10.0
  /usr/local/share/perl/5.10.0
  /usr/lib/perl5
  /usr/share/perl5
  /usr/lib/perl/5.10
  /usr/share/perl/5.10
  /usr/local/lib/site_perl
  .


Environment for perl 5.10.0​:
  HOME=/home/derf
  LANG=en_US.UTF-8
  LANGUAGE (unset)
  LD_LIBRARY_PATH (unset)
  LOGDIR (unset)
  PATH=/home/derf/bin​:/usr/local/bin​:/usr/bin​:/bin​:/usr/bin/X11​:/usr/games​:/sbin​:/usr/sbin​:/usr/local/sbin
  PERL_BADLANG (unset)
  SHELL=zsh

@p5pRT
Copy link
Author

p5pRT commented Apr 11, 2009

From derf@sievert.tabularazor.org

Sorry for bothering you, seems like the bug was fixed some months ago
(and it does not occur in the perl git version).

This ticket can be closed, I guess.

[for the record​: I searched for the bug before reporting it, but RT
fails when searching for a % and I didn't think of searching for "leak"
instead ;) ]

@p5pRT
Copy link
Author

p5pRT commented Apr 14, 2009

From @iabyn

On Sat, Apr 11, 2009 at 10​:26​:22AM -0700, Daniel Friesel wrote​:

-----------------------------------------------------------------
Apparently, accessing %+ after using named capture buffers causes memory leaks.
I tested the following snippet on various systems,
it consumes 200-400MB of memory.

-- snip --
#!/usr/bin/env perl
# use strict/warnings/5.010 do not affect this
use strict;
use warnings;
use 5.010;
my @​trash;

print "PID​: $$\n";
print "Doing stuff...\n";

for(my $i = 0; $i < 900000; $i++) {
"foo bar quux spam ham eggs" =~ /^(?<foo>\w+) (?<bar>\w+) (?<quux>\w+) (?<spam>\w+) (?<ham>\w+) (?<eggs>\w+)$/;
# the memory leak does not occur when %+ is not used
# (not related to slicing, though)
@​trash = @​+{'foo', 'bar', 'quux', 'spam', 'ham', 'eggs'};
}

print "done\n";
print "memory usage should be somewhere around 200M now, mind checking?\n";
print "(you can kill me afterwards)\n";

sleep();

I can't reproduce this on any of the 5.10.0 binaries I have, nor in blead
or maint-5.10.

Running under valgrind shows no significant leakage, but *does* show that
total mallocs were around 205Mb. So I'm wondering whether there is some
bug in the malloc library instead?

Can anyone else reproduce this?

--
Technology is dominated by two types of people​: those who understand what
they do not manage, and those who manage what they do not understand.

@p5pRT
Copy link
Author

p5pRT commented Apr 14, 2009

The RT System itself - Status changed from 'new' to 'open'

@p5pRT
Copy link
Author

p5pRT commented Jul 20, 2016

From @dcollinsn

This was reported fixed by the original submitter shortly after opening the ticket.

--
Respectfully,
Dan Collins

@p5pRT p5pRT closed this as completed Jul 20, 2016
@p5pRT
Copy link
Author

p5pRT commented Jul 20, 2016

@dcollinsn - Status changed from 'open' to 'resolved'

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant