From jnarron@cdsinet.net

This is a bug report for perl from jnarron@​cdsinet.net,
generated with the help of perlbug 1.35 running under perl v5.8.7.

I came across this problem when not only myself, but several other
FreeBSD users upgraded to perl 5.8.7 and were noticing that their
amavisd-new installations were not working properly. After some
testing and digging, it turns out that spamassassin 3.0 was causing
a bus error. Using the perl debugger, the line causing the bus
error turns out to be​:

DB<4> v
1955 EOT
1956
1957 # and run it.
1958==> eval $evalstr;
1959​: if ($@​) {
1960​: warn("Failed to compile URI SpamAssassin tests, skipping​:\n".
1961 "\t($@​)\n");
1962​: $self->{rule_errors}++;
1963 }
1964 else {

eXamining $evalstr produces an incredibly lengthy string full of
many if statements. Using a debug version of perl 5.8.7, and gdb​:

#0 0x280a2144 in Perl_malloc (nbytes=25) at malloc.c​:1411
#1 0x281075b5 in S_save_hek_flags (str=0x935b328 "WLS_URI_OPT_377", len=15, hash=1020016264, flags=0) at hv.c​:97
#2 0x2810aa51 in S_share_hek_flags (str=0x935b328 "WLS_URI_OPT_377", len=15, hash=1020016264, flags=0) at hv.c​:2114
#3 0x2810a940 in Perl_share_hek (str=0x935b328 "WLS_URI_OPT_377", len=15, hash=1020016264) at hv.c​:2074
#4 0x28129e29 in Perl_newSVpvn_share (src=0x935b328 "WLS_URI_OPT_377", len=15, hash=1020016264) at sv.c​:6876
#5 0x280def33 in Perl_peep (o=0x935f288) at op.c​:6699
#6 0x280debcc in Perl_peep (o=0x935ef88) at op.c​:6634
... (lots of calls to Perl_peep, o= different numbers each time.. I'm assuming it's a recursive function)
#5432 0x280debcc in Perl_peep (o=0x8081108) at op.c​:6634
#5433 0x280debcc in Perl_peep (o=0x8587a48) at op.c​:6634
#5434 0x280debcc in Perl_peep (o=0x8062b08) at op.c​:6634
#5435 0x280d10d5 in Perl_newPROG (o=0x8062b88) at op.c​:1952
#5436 0x280cac39 in Perl_yyparse () at perly.y​:140
#5437 0x28155eb7 in S_doeval (gimme=128, startop=0x0, outside=0x805829c, seq=0) at pp_ctl.c​:2892
#5438 0x281588ef in Perl_pp_entereval () at pp_ctl.c​:3486
#5439 0x280f8ebe in Perl_runops_debug () at dump.c​:1452 #5440 0x2809be1f in S_run_body (oldscope=1) at perl.c​:2000
#5441 0x2809b8d5 in perl_run (my_perl=0x804e1f0) at perl.c​:1919
#5442 0x08049188 in main ()

This happens on line 21720 of the $evalstr, and the following was also noticed​:
(5434 (first Perl_peep line) - 4 (line after last Perl_peep) * 4 = 21720

FreeBSD 5.4 seems to have a default stack hardlimit of 64MB. Increasing
this hardlimit to 128MB (by changing the MAXSSIZ option in the kernel)
allows eval to process more lines of $evalstr, but still not enough to
get all the way through. Originally, perl 5.8.7 was compiled with CFLAGS
of -O2, but changing CFLAGS to -O0 didn't help either. Changing CFLAGS to
-Os however did the trick.

This is reproducable on 2 other FreeBSD 5.4 systems. This bus error
does not occur with perl 5.8.5 or perl 5.8.6 on these same systems.
This bus error also does not appear on a tested Linux 2.6 (with an
unlimited stack), or on an OpenBSD 3.7 (with an 8M stack). I have
test cases that I'm willing to send, but not attaching due to their
sizes.

Flags​:
  category=core
  severity=medium

Site configuration information for perl v5.8.7​:

Configured by root at Mon Jul 25 16​:56​:21 CDT 2005.

Summary of my perl5 (revision 5 version 8 subversion 7) configuration​:
  Platform​:
  osname=freebsd, osvers=5.4-release-p4, archname=i386-freebsd-64int
  uname='freebsd freebsd.cdsinet.net 5.4-release-p4 freebsd 5.4-release-p4 #12​: wed jul 6 10​:39​:12 cdt 2005 zeek@​freebsd.cdsinet.net​:usrobjusrsrcsysnoaa i386 '
  config_args='-sde -Dprefix=/usr/local -Darchlib=/usr/local/lib/perl5/5.8.7/mach -Dprivlib=/usr/local/lib/perl5/5.8.7 -Dman3dir=/usr/local/lib/perl5/5.8.7/perl/man/man3 -Dman1dir=/usr/local/man/man1 -Dsitearch=/usr/local/lib/perl5/site_perl/5.8.7/mach -Dsitelib=/usr/local/lib/perl5/site_perl/5.8.7 -Dscriptdir=/usr/local/bin -Dsiteman3dir=/usr/local/lib/perl5/5.8.7/man/man3 -Dsiteman1dir=/usr/local/man/man1 -Ui_malloc -Ui_iconv -Uinstallusrbinperl -Dcc=cc -Duseshrplib -Dccflags=-DAPPLLIB_EXP="/usr/local/lib/perl5/5.8.7/BSDPAN" -Doptimize=-Os -Ud_dosuid -Ui_gdbm -Dusethreads=n -Dusemymalloc=n -Duse64bitint'
  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=undef
  usemymalloc=n, bincompat5005=undef
  Compiler​:
  cc='cc', ccflags ='-DAPPLLIB_EXP="/usr/local/lib/perl5/5.8.7/BSDPAN" -DHAS_FPSETMASK -DHAS_FLOATINGPOINT_H -fno-strict-aliasing -pipe -I/usr/local/include',
  optimize='-Os',
  cppflags='-DAPPLLIB_EXP="/usr/local/lib/perl5/5.8.7/BSDPAN" -DHAS_FPSETMASK -DHAS_FLOATINGPOINT_H -fno-strict-aliasing -pipe -I/usr/local/include'
  ccversion='', gccversion='3.4.2 [FreeBSD] 20040728', 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='double', nvsize=8, Off_t='off_t', lseeksize=8
  alignbytes=4, prototype=define
  Linker and Libraries​:
  ld='cc', ldflags ='-pthread -Wl,-E -L/usr/local/lib'
  libpth=/usr/lib /usr/local/lib
  libs=-lgdbm -lm -lcrypt -lutil
  perllibs=-lm -lcrypt -lutil
  libc=, so=so, useshrplib=true, libperl=libperl.so
  gnulibc_version=''
  Dynamic Linking​:
  dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags=' -Wl,-R/usr/local/lib/perl5/5.8.7/mach/CORE'
  cccdlflags='-DPIC -fPIC', lddlflags='-shared -L/usr/local/lib'

Locally applied patches​:
  defined-or

@​INC for perl v5.8.7​:
  /usr/local/lib/perl5/site_perl/5.8.7
  /usr/local/lib/perl5/site_perl/5.8.7/mach
  /usr/local/lib/perl5/site_perl
  /usr/local/lib/perl5/5.8.7/BSDPAN
  /usr/local/lib/perl5/5.8.7/mach
  /usr/local/lib/perl5/5.8.7
  .

Environment for perl v5.8.7​:
  HOME=/home/z/zeek
  LANG (unset)
  LANGUAGE (unset)
  LC_ALL=POSIX
  LD_LIBRARY_PATH (unset)
  LOGDIR (unset)
  PATH=/sbin​:/bin​:/usr/sbin​:/usr/bin​:/usr/games​:/usr/local/sbin​:/usr/local/bin​:/usr/X11R6/bin​:/home/z/zeek/bin​:/home/z/zeek/bin​:.
  PERL_BADLANG (unset)
  SHELL=/usr/local/bin/bash

From @iabyn

On Wed, Jul 27, 2005 at 08​:21​:01AM -0700, jnarron @​ cdsinet. net wrote​:

I have test cases that I'm willing to send, but not attaching due to
their sizes.

Could you send them as a tar.gz attachment please?

--
Thank God I'm an atheist.....

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

From jnarron@cdsinet.net

The following script also produces similar results​:

perl -e 'my $x = q[if ($h->{ALPHA}->{BETA}->{q{stuff}}) {] . "\n" . q[
stuff($h, @​_);] . "\n}\n\n"; $x x= 7238; $x =~ s/stuff/"stuff" .
++$count/eg; eval $x'

Adjusting the x= XXXX makes a bit more flexible test case. 7238 doesn't
crash, but 7239 does.

From jnarron@cdsinet.net

testcases.tar.gz

From shouldbedomo@mac.com

On 2005–07–27, at 20​:31, John Narron wrote​:

perl -e 'my $x = q[if ($h->{ALPHA}->{BETA}->{q{stuff}}) {] . "\n" . q[
stuff($h, @​_);] . "\n}\n\n"; $x x= 7238; $x =~ s/stuff/"stuff" .
++$count/eg; eval $x'

Problem confirmed with the above script on Mac OS X. The tipping
point for a debugging bleadperl@​25218 with a stack limit of 8192k is
$x x= 26197. For a 64-bit perl it's somewhat more than half that; for
a production perl 5.8.6, it's much higher -- somewhere between 70 and
80,000. I'd put that difference down to the lack of debugging
overhead and to optimisation, but I don't have an optimised bleadperl
handy to check. The stack trace of a the crashed perl 5.8.6 looks like

Host Name​: Tullamore
Date/Time​: 2005-07-28 08​:42​:07.312 +0200
OS Version​: 10.4.2 (Build 8C46)
Report Version​: 3

Command​: perl
Path​: /sw/bin/perl
Parent​: bash [300]

Version​: ??? (???)

PID​: 2876
Thread​: 0

Exception​: EXC_BAD_ACCESS (0x0001)
Codes​: KERN_INVALID_ADDRESS (0x0001) at 0xbf7ffff0

Thread 0 Crashed​:
0 perl 0x0002ffd0 Perl_newSV + 16 (crt.c​:300)
1 perl 0x00081164 Perl_av_fetch + 688 (crt.c​:300)
2 perl 0x000b0268 Perl_pad_alloc + 236 (crt.c​:300)
3 perl 0x000179d4 Perl_peep + 496 (crt.c​:300)
4 perl 0x00017fe4 Perl_peep + 2048 (crt.c​:300)
5 perl 0x00017fe4 Perl_peep + 2048 (crt.c​:300)
... [you get the idea]
501 perl 0x00017fe4 Perl_peep + 2048 (crt.c​:300)
502 perl 0x00017fe4 Perl_peep + 2048 (crt.c​:300)
503 perl 0x00017fe4 Perl_peep + 2048 (crt.c​:300)
504 perl 0x00017fe4 Perl_peep + 2048 (crt.c​:300)
505 perl 0x00017fe4 Perl_peep + 2048 (crt.c​:300)
506 perl 0x00017fe4 Perl_peep + 2048 (crt.c​:300)
507 perl 0x00017fe4 Perl_peep + 2048 (crt.c​:300)
508 perl 0x00017fe4 Perl_peep + 2048 (crt.c​:300)

Thread 0 crashed with PPC Thread State 64​:
  srr0​: 0x000000000002ffd0 srr1​:
0x100000000000d030 vrsave​: 0x0000000000000000
  cr​: 0x28004284 xer​: 0x0000000000000000 lr​:
0x0000000000081164 ctr​: 0x000000000003177c
  r0​: 0x0000000000081164 r1​: 0x00000000bf800040 r2​:
0x0000000000000000 r3​: 0x0000000001800400
  r4​: 0x0000000000000000 r5​: 0x00000000000e69ad r6​:
0x0000000000000001 r7​: 0x0000000001a1d200
  r8​: 0x000000000000006f r9​: 0x000000000b005000 r10​:
0x000000000000007f r11​: 0x00000000018028c0
  r12​: 0x000000009000a770 r13​: 0x0000000000000000 r14​:
0x0000000000000000 r15​: 0x0000000000000000
  r16​: 0x0000000000000000 r17​: 0x0000000000000000 r18​:
0x0000000000000000 r19​: 0x000000000000012c
  r20​: 0x0000000000000002 r21​: 0x0000000000305c50 r22​:
0x000000000180be00 r23​: 0x000000000180ba00
  r24​: 0x000000000dbaf6b0 r25​: 0x0000000000000001 r26​:
0x0000000000000003 r27​: 0x000000000180b60c
  r28​: 0x0000000001800400 r29​: 0x0000000001800400 r30​:
0x0000000001800400 r31​: 0x0000000000080ec4

Binary Images Description​:
  0x1000 - 0xd9fff perl /sw/bin/perl
0x8fe00000 - 0x8fe51fff dyld 43.1 /usr/lib/dyld
0x90000000 - 0x901a6fff libSystem.B.dylib /usr/lib/libSystem.B.dylib
0x901fe000 - 0x90202fff libmathCommon.A.dylib /usr/lib/system/
libmathCommon.A.dylib

--
Dominic Dunlop

From shouldbedomo@mac.com

On 2005–07–28, at 08​:51, Dominic Dunlop wrote​:

On 2005–07–27, at 20​:31, John Narron wrote​:

perl -e 'my $x = q[if ($h->{ALPHA}->{BETA}->{q{stuff}}) {] .
"\n" . q[
stuff($h, @​_);] . "\n}\n\n"; $x x= 7238; $x =~ s/stuff/"stuff" .
++$count/eg; eval $x'

Problem confirmed with the above script on Mac OS X. The tipping
point for a debugging bleadperl@​25218 with a stack limit of 8192k
is $x x= 26197. For a 64-bit perl it's somewhat more than half
that; for a production perl 5.8.6, it's much higher -- somewhere
between 70 and 80,000.

Another data point​: the problem's not specific to eval -- with this
variant of the program, which pipes the generated script to a child
perl, the child perl blows its stack at almost exactly the same point
(21969 vs 21968) as in the original.

./perl -e 'my $x = q[if ($h->{ALPHA}->{BETA}->{q{stuff}}) {] . "\n" . q[
stuff($h, @​_);] . "\n}\n\n"; $x x= 26199; $x =~ s/stuff/"stuff" .
++$count/eg;$x .= q(print "done\n";); open P, "|./perl -w" or die
"Pipe open failed​: !$\n"; print P $x; close P'

--
Dominic Dunlop

From shouldbedomo@mac.com

On 2005–07–28, at 08​:51, Dominic Dunlop wrote​:

On 2005–07–27, at 20​:31, John Narron wrote​:

perl -e 'my $x = q[if ($h->{ALPHA}->{BETA}->{q{stuff}}) {] .
"\n" . q[
stuff($h, @​_);] . "\n}\n\n"; $x x= 7238; $x =~ s/stuff/"stuff" .
++$count/eg; eval $x'

Problem confirmed with the above script on Mac OS X. The tipping
point for a debugging bleadperl@​25218 with a stack limit of 8192k
is $x x= 26197. For a 64-bit perl it's somewhat more than half
that; for a production perl 5.8.6, it's much higher -- somewhere
between 70 and 80,000. I'd put that difference down to the lack of
debugging overhead and to optimisation, but I don't have an
optimised bleadperl handy to check. The stack trace of a the
crashed perl 5.8.6 looks like
...
Thread 0 Crashed​:
0 perl 0x0002ffd0 Perl_newSV + 16 (crt.c​:300)
1 perl 0x00081164 Perl_av_fetch + 688 (crt.c​:300)
2 perl 0x000b0268 Perl_pad_alloc + 236 (crt.c​:300)
3 perl 0x000179d4 Perl_peep + 496 (crt.c​:300)
4 perl 0x00017fe4 Perl_peep + 2048 (crt.c​:300)
5 perl 0x00017fe4 Perl_peep + 2048 (crt.c​:300)
... [you get the idea]
501 perl 0x00017fe4 Perl_peep + 2048 (crt.c​:300)
502 perl 0x00017fe4 Perl_peep + 2048 (crt.c​:300)
503 perl 0x00017fe4 Perl_peep + 2048 (crt.c​:300)
504 perl 0x00017fe4 Perl_peep + 2048 (crt.c​:300)
505 perl 0x00017fe4 Perl_peep + 2048 (crt.c​:300)
506 perl 0x00017fe4 Perl_peep + 2048 (crt.c​:300)
507 perl 0x00017fe4 Perl_peep + 2048 (crt.c​:300)
508 perl 0x00017fe4 Perl_peep + 2048 (crt.c​:300)

Attached is a comprehensive but simple-minded patch that simply stops
Perl_peep from recursing to a depth a greater than 8192. When this
happens, you get a warning, and the code gets run unoptimized. A
better approach would be to find out why the optimizer thinks it
needs such a large peephole in this case (more a picture window,
really) and persuade it to be less ambitious. But I don't understand
the optimizer at all -- hence the crude solution.

Run embed.pl after applying the patch. Passes all tests for me both
unthreaded and threaded.

The figure of 8192 is arbitrary​: it's comfortably higher than the
deepest recursion I measured during make test -- 878 levels.
(Measurement code not in patch.) OTOH it's higher than the value that
John Narron reported as causing his crash. Why is this? Because with
an unoptimized build of bleadperl for Darwin, I can only make John's
example crash rather than hitting the limit enforced by the patch if
I reduce stack size to 2MB. With an optimized perl, I must reduce
stack size to 1MB to get a crash. I think it's fair to expect that
perl will have at least 4MB of stack to play with on most platforms.
This leaves some headroom after the depth limit of 8192 is reached,
even on platforms which use more stack than PowerPC. (If you really
want to change the limit, -DPERL_PEEP_LIMIT=your_number when
compiling op.c, although this will make the warnings test fail,
because it's expecting to see '8192'.)

The original report says

FreeBSD 5.4 seems to have a default stack hardlimit of 64MB.

I think that either John must be mistaken, or FreeBSD's stackframes
are so incredibly large that somebody should look into shrinking them.

As the patch adds entry and exit code to a function that's called a
lot, here are some benchmarks from make minitest with perl@​25260​:

perl-current-optimized​:
u=1.27 s=0.94 cu=44.60 cs=14.23 scripts=207 tests=49777
u=1.23 s=0.80 cu=44.73 cs=14.07 scripts=207 tests=49777

perl-current-patched-optimized​:
u=1.27 s=0.86 cu=43.32 cs=14.41 scripts=207 tests=49777
u=1.24 s=0.82 cu=43.17 cs=14.04 scripts=207 tests=49777

perl-current-optimized-threads​:
u=2.54 s=0.99 cu=104.48 cs=17.09 scripts=207 tests=49777
u=2.51 s=0.90 cu=104.40 cs=16.70 scripts=207 tests=49777

perl-current-patched-optimized-threads​:
u=2.50 s=0.94 cu=106.50 cs=17.11 scripts=207 tests=49777
u=2.50 s=0.89 cu=106.29 cs=16.79 scripts=207 tests=49777

3% _better_ on user time for unthreaded; 2% penalty for threaded. Ah
well. There's another optimizer I don't understand. I'd say it was
down in the noise if it wasn't so repeatable...
--
Dominic Dunlop

From shouldbedomo@mac.com

optcrash-patch

From @iabyn

On Thu, Aug 04, 2005 at 09​:52​:18PM +0200, Dominic Dunlop wrote​:

Attached is a comprehensive but simple-minded patch that simply stops
Perl_peep from recursing to a depth a greater than 8192. When this
happens, you get a warning, and the code gets run unoptimized.

Perl_peep doesn't just do omptimisations; swome stuff is necessary for
normal running, eg

  case OP_METHOD_NAMED​:
  /* Relocate sv to the pad for thread safety.

better approach would be to find out why the optimizer thinks it
needs such a large peephole in this case (more a picture window,
really) and persuade it to be less ambitious. But I don't understand
the optimizer at all -- hence the crude solution.

The optimiser processes ops in the order they're normally executed.
For stuff like boolean ops, there's a branch of code which isn't in the
'normal' execution path, eg

  if (foo) { bar}
  baz;

which is the same as

  foo && bar; baz;

the 'normal' path is foo -> baz. So peep recurses down the 'other' branch
to make sure it gets processed too. However, when it follows the bar path,
the next op after bar is baz, so it continues its merry way into the next
statement. Eventually it finisheds returns, and the top-level peep
continues with the next op, baz, but finds it's already been processed,
and so quits.

The fix would probably be to temporary set the 'done' flag on the next op
before recursing. But I havn't got time to look into this yet.

--
I've often wanted to drown my troubles, but I can't get my wife to go
swimming.

From shouldbedomo@mac.com

Pumpking(s), please don't apply my patch, as it may be unsafe despite
getting through the test suite​:

On 2005–08–05, at 01​:46, Dave Mitchell wrote​:

Perl_peep doesn't just do omptimisations; swome stuff is necessary for
normal running, eg

case OP\_METHOD\_NAMED​:
    /\* Relocate sv to the pad for thread safety\.

I wondered about stuff like that, and thought I thrashed the patch
fairly hard on threading until nothing broke. Do you have time to
suggest a test or tests that will fail when such things are not done?

... So peep recurses down the 'other' branch [of a conditional] to
make sure it gets processed too.
...
The fix would probably be to temporary set the 'done' flag on the
next op
before recursing. But I havn't got time to look into this yet.

Thanks for the insight. Time to delve into the code ...
--
Dominic Dunlop

From jnarron@gmail.com

This has just been an incredibly odd week for me, so I haven't been
able to keep up with all of this.

Anyway, after making this bug report and doing a lot of testing, I've
boiled it down to a problem with perl 5.8.7 being linked with
libpthread on FreeBSD 5.4. Now the simple solution is​: don't link it
with pthread! (or, don't build a threaded perl). Well, I didn't. For
some reason though, the perl port decided to link in pthread regardless
of whether the WITH_THREADS= option was specified as a yes or no. This
is a ports bug problem, and a PR already submitted​:

http​://www.freebsd.org/cgi/query-pr.cgi?pr=84255

Once I changed the port patches to ensure pthread wasn't linked in, it
works just beautifully. Infact, I ran a test case with over 100,000 if
() statements and it worked fine (took a while, but ran fine). I kept
increasing the test case length until perl started reporting an out-of-
memory condition, which is what I believe is supposed to happen anyway.

So now, in my opinion, it appears to be something between perl 5.8.7
(maybe earlier, not sure) and the pthread lib on FreeBSD 5.4. I don't
have many machines I can test earlier versions on.

The original report says

FreeBSD 5.4 seems to have a default stack hardlimit of 64MB.

I think that either John must be mistaken, or FreeBSD's stackframes
are so incredibly large that somebody should look into shrinking them.

Wouldn't be the first time I was wrong, and I'm only human :)

However, taken from /usr/src/sys/conf/NOTES​:

options MAXSSIZ=(128UL*1024*1024)

128*1024*1024 = 134,217,728

root​:~# ulimit -s
131072

131072 * 1024 = 134,217,728

Again, I'm no expert, never said I was, just going on what I observe.

From jnarron@gmail.com

However, taken from /usr/src/sys/conf/NOTES​:

options MAXSSIZ=(128UL*1024*1024)

128*1024*1024 = 134,217,728

root​:~# ulimit -s
131072

131072 * 1024 = 134,217,728

Got ahead of myself on this one. If you add that 'options' line to the
kernel config, recompile, and reboot, your stack size hard limit is set
to 131072 (or 128MB). Without that 'options' line, ulimit -s spits out
65536 (or 64MB).

From @ysth

On Fri, Aug 05, 2005 at 08​:43​:41AM +0200, Dominic Dunlop wrote​:

Pumpking(s), please don't apply my patch, as it may be unsafe despite
getting through the test suite​:

On 2005?08?05, at 01​:46, Dave Mitchell wrote​:

Perl_peep doesn't just do omptimisations; swome stuff is necessary for
normal running, eg

case OP_METHOD_NAMED​:
/* Relocate sv to the pad for thread safety.

I wondered about stuff like that, and thought I thrashed the patch
fairly hard on threading until nothing broke. Do you have time to
suggest a test or tests that will fail when such things are not done?

... So peep recurses down the 'other' branch [of a conditional] to
make sure it gets processed too.
...
The fix would probably be to temporary set the 'done' flag on the
next op
before recursing. But I havn't got time to look into this yet.

Thanks for the insight. Time to delve into the code ...

FWIW, I thought making sure only optional stuff was in the optimizing
code was on Hugo's list of stuff wanted in 5.10.

Definitely worth pursuing.

From @tonycoz

On Wed, 27 Jul 2005 23​:51​:55 -0700, shouldbedomo@​mac.com wrote​:

Thread 0 Crashed​:
0 perl 0x0002ffd0 Perl_newSV + 16 (crt.c​:300)
1 perl 0x00081164 Perl_av_fetch + 688 (crt.c​:300)
2 perl 0x000b0268 Perl_pad_alloc + 236 (crt.c​:300)
3 perl 0x000179d4 Perl_peep + 496 (crt.c​:300)
4 perl 0x00017fe4 Perl_peep + 2048 (crt.c​:300)
5 perl 0x00017fe4 Perl_peep + 2048 (crt.c​:300)
... [you get the idea]
501 perl 0x00017fe4 Perl_peep + 2048 (crt.c​:300)
502 perl 0x00017fe4 Perl_peep + 2048 (crt.c​:300)
503 perl 0x00017fe4 Perl_peep + 2048 (crt.c​:300)
504 perl 0x00017fe4 Perl_peep + 2048 (crt.c​:300)
505 perl 0x00017fe4 Perl_peep + 2048 (crt.c​:300)
506 perl 0x00017fe4 Perl_peep + 2048 (crt.c​:300)
507 perl 0x00017fe4 Perl_peep + 2048 (crt.c​:300)
508 perl 0x00017fe4 Perl_peep + 2048 (crt.c​:300)

This appears to have been largely fixed by 3c78429.

Tony

From @tonycoz

On Tue, 29 Jan 2019 15​:48​:07 -0800, tonyc wrote​:

On Wed, 27 Jul 2005 23​:51​:55 -0700, shouldbedomo@​mac.com wrote​:

Thread 0 Crashed​:
0 perl 0x0002ffd0 Perl_newSV + 16 (crt.c​:300)
1 perl 0x00081164 Perl_av_fetch + 688 (crt.c​:300)
2 perl 0x000b0268 Perl_pad_alloc + 236 (crt.c​:300)
3 perl 0x000179d4 Perl_peep + 496 (crt.c​:300)
4 perl 0x00017fe4 Perl_peep + 2048 (crt.c​:300)
5 perl 0x00017fe4 Perl_peep + 2048 (crt.c​:300)
... [you get the idea]
501 perl 0x00017fe4 Perl_peep + 2048 (crt.c​:300)
502 perl 0x00017fe4 Perl_peep + 2048 (crt.c​:300)
503 perl 0x00017fe4 Perl_peep + 2048 (crt.c​:300)
504 perl 0x00017fe4 Perl_peep + 2048 (crt.c​:300)
505 perl 0x00017fe4 Perl_peep + 2048 (crt.c​:300)
506 perl 0x00017fe4 Perl_peep + 2048 (crt.c​:300)
507 perl 0x00017fe4 Perl_peep + 2048 (crt.c​:300)
508 perl 0x00017fe4 Perl_peep + 2048 (crt.c​:300)

This appears to have been largely fixed by
3c78429.

And closing.

If you have new test cases that cause similar crashes please open a new ticket.

Tony

@tonycoz - Status changed from 'open' to 'pending release'

From @khwilliamson

Thank you for filing this report. You have helped make Perl better.

With the release today of Perl 5.30.0, this and 160 other issues have been
resolved.

Perl 5.30.0 may be downloaded via​:
https://metacpan.org/release/XSAWYERX/perl-5.30.0

If you find that the problem persists, feel free to reopen this ticket.

@khwilliamson - Status changed from 'pending release' to 'resolved'