Closed p5pRT closed 20 years ago
The following line cause perl to do a segmentation fault:
perl -e '$i = "i" x 30000; $i =~ /(?:[^@]|@@)*/gc;'
It seems the limit is arround 27000 characters and depend on the number of @@ eventually present.
Thanks for your bug report. Version 5.6 does not core dump on:
perl -e '$i = "i" x 30000; $i =~ /(?:[^@]|@@)*/gc;'
I've marked the bug as closed.
Cheers;
Nat
At 20:44 -0700 2000-03-20\, Nathan Torkington wrote:
Thanks for your bug report. Version 5.6 does not core dump on:
perl -e '$i = "i" x 30000; $i =~ /(?:[^@]|@@)*/gc;'
I've marked the bug as closed.
For completeness\, follow the perl manpage's sage advice:
If something strange has gone wrong with your program and you're not sure where you should look for help\, try the -w switch first. It will often point out exactly where the trouble is.
perl -we '$i = "i" x 30000; $i =~ /(?:[^@]|@@)*/gc;' Complex regular subexpression recursion limit (2046) exceeded at -e line 1.
(I have a particularly weedy complex regular subexpression recursion limit; you'll see 32766 most other systems.) -- Dominic Dunlop
In \14550\.61491\.534434\.775503@​prometheus\.frii\.com\, Nathan Torkington writes: :Thanks for your bug report. Version 5.6 does not core dump on: : : perl -e '$i = "i" x 30000; $i =~ /(?:[^@] | @@)*/gc;' |
---|
:I've marked the bug as closed.
RC2 core dumps here:
crypt% perl -we '$i = "i" x 30000; $i =~ /(?:[^@]|@@)*/gc;' Segmentation fault (core dumped) crypt%
Is this not the standard stacksize issue?
Hugo
Summary of my perl5 (revision 5.0 version 6 subversion 0) configuration: Platform: osname=linux\, osvers=2.2.5-16\, archname=i686-linux-64int uname='linux crypt.compulink.co.uk 2.2.5-16 #1 sun may 30 23:00:18 bst 1999 i686 unknown ' config_args='-des -Doptimize=-g -O6 -Dprefix=/opt/perl-5.6.0-RC2.64bit -Duse64bitint' hint=recommended\, useposix=true\, d_sigaction=define usethreads=undef use5005threads=undef useithreads=undef usemultiplicity=undef useperlio=undef d_sfio=undef uselargefiles=define use64bitint=define use64bitall=undef uselongdouble=undef usesocks=undef Compiler: cc='cc'\, optimize='-g -O6'\, gccversion=egcs-2.91.66 19990314/Linux (egcs-1.1.2 release) cppflags='-DDEBUGGING -fno-strict-aliasing' ccflags ='-DDEBUGGING -fno-strict-aliasing -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64' stdchar='char'\, d_stdstdio=define\, usevfork=false intsize=4\, longsize=4\, ptrsize=4\, doublesize=8 d_longlong=define\, longlongsize=8\, d_longdbl=define\, longdblsize=12 ivtype='long long'\, ivsize=8\, nvtype='double'\, nvsize=8\, Off_t='off_t'\, lseeksize=8 alignbytes=4\, usemymalloc=n\, prototype=define Linker and Libraries: ld='cc'\, ldflags =' -L/usr/local/lib' libpth=/usr/local/lib /lib /usr/lib libs=-lnsl -lndbm -lgdbm -ldb -ldl -lm -lc -lposix -lcrypt libc=/lib/libc-2.1.1.so\, so=so\, useshrplib=false\, libperl=libperl.a Dynamic Linking: dlsrc=dl_dlopen.xs\, dlext=so\, d_dlsymun=undef\, ccdlflags='-rdynamic' cccdlflags='-fpic'\, lddlflags='-shared -L/usr/local/lib'
Characteristics of this binary (from libperl): Compile-time options: DEBUGGING USE_64_BIT_INT USE_LARGE_FILES Locally applied patches: v5.6.0-RC2 Built under linux Compiled at Mar 15 2000 11:20:32 @INC: /opt/perl-5.6.0-RC2.64bit/lib/5.6.0/i686-linux-64int /opt/perl-5.6.0-RC2.64bit/lib/5.6.0 /opt/perl-5.6.0-RC2.64bit/lib/site_perl/5.6.0/i686-linux-64int /opt/perl-5.6.0-RC2.64bit/lib/site_perl/5.6.0 /opt/perl-5.6.0-RC2.64bit/lib/site_perl .
In \p04310108b4fce2bf145b@​\[192\.168\.1\.4\]\, Dominic Dunlop writes: :At 20:44 -0700 2000-03-20\, Nathan Torkington wrote: :>Thanks for your bug report. Version 5.6 does not core dump on: :> :> perl -e '$i = "i" x 30000; $i =~ /(?:[^@] | @@)*/gc;' :> :>I've marked the bug as closed. |
---|
:For completeness\, follow the perl manpage's sage advice: : : If something strange has gone wrong with your program and : you're not sure where you should look for help\, try the -w : switch first. It will often point out exactly where the : trouble is. : :perl -we '$i = "i" x 30000; $i =~ /(?:[^@]|@@)*/gc;' :Complex regular subexpression recursion limit (2046) exceeded at -e line 1.
That won't help if you are getting core dumps due to too high a CRSRL.
Hugo
At 11:20 +0000 2000-03-21\, Hugo wrote:
:Complex regular subexpression recursion limit (2046) exceeded at -e line 1.
That won't help if you are getting core dumps due to too high a CRSRL.
Quite. The warning is not triggered by all dangerously recursive regexps\, which remain a way of making perl reliably dump core (if that isn't an oxymoron). Allowing perl a higher stack size limit's the only way out of that one -- and even then\, one needs an arbitrarily large limit to be anywhere near totally safe. Maybe once 5.6 is out\, I'll try tapping my head against the stack overflow check wall one more time. (See http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/1999-09/msg01234.html).
The favoured fix\, flattening the regexp engine\, isn't on the todo list. Maybe it should be. (See http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/1999-07/msg01177.html.) -- Dominic Dunlop
Migrated from rt.perl.org#839 (status was 'resolved')
Searchable as RT839$