From @jhi

The following strange piece of code *) seems to evoke the
angry god of Seg Fault in Perl's 5.005_58-to-be, 5.00556,
5.005_03, 5.004_04, in Digital UNIX 4.0D​:

$c = [[]];
$#{$c->[$c->[0]]}

*) Yes, the snippet makes no sense​: an array ref indexed by an
  anonymous list? No, I am not expecting any useful answer from
  the snippet, either​: in the heat of hacking a throw-away script,
  between edits, I just stumbled into this.

Site configuration information for perl 5.00557:

Configured by jhi at Thu Jul 15 17:13:20 EET DST 1999.

Summary of my perl5 (revision 5.0 version 5 subversion 57) configuration:
  Platform:
    osname=dec_osf, osvers=4.0, archname=alpha-dec_osf
    uname='osf1 alpha.hut.fi v4.0 878 alpha '
    config_args='-ders'
    hint=recommended, useposix=true, d_sigaction=define
    usethreads=undef useperlio=undef d_sfio=undef
    use64bits=undef usemultiplicity=undef
  Compiler:
    cc='cc', optimize='-O4', gccversion=
    cppflags='-std -ieee -D_INTRINSICS -DLANGUAGE_C'
    ccflags ='-std -fprm d -ieee -D_INTRINSICS -DLANGUAGE_C'
    stdchar='unsigned char', d_stdstdio=define, usevfork=false
    intsize=4, longsize=8, ptrsize=8, doublesize=8
    d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=8
    alignbytes=8, usemymalloc=y, prototype=define
  Linker and Libraries:
    ld='ld', ldflags =''
    libpth=/usr/shlib /usr/ccs/lib /usr/lib/cmplrs/cc /usr/lib /var/shlib
    libs=-lgdbm -ldbm -ldb -lm -lrt
    libc=, so=so, useshrplib=true, libperl=libperl.so
  Dynamic Linking:
    dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='  -Wl,-rpath,/usr/local/lib/perl5/5.00557/alpha-dec_osf/CORE'
    cccdlflags=' ', lddlflags='-shared -expect_unresolved "*" -msym -s'

Locally applied patches:
    


@INC for perl 5.00557:
    lib
    /u/vieraat/vieraat/jhi/Perl/lib
    /usr/local/lib/perl5/5.00557/alpha-dec_osf
    /usr/local/lib/perl5/5.00557
    /usr/local/lib/perl5/site_perl/5.00557/alpha-dec_osf
    /usr/local/lib/perl5/site_perl/5.00557
    .


Environment for perl 5.00557:
    HOME=/u/vieraat/vieraat/jhi
    LANG=C
    LANGUAGE (unset)
    LC_ALL=fi_FI.ISO8859-1
    LC_CTYPE=fi_FI.ISO8859-1
    LD_LIBRARY_PATH=/u/vieraat/vieraat/jhi/pp4/cfgperl
    LOGDIR (unset)
    PATH=/u/vieraat/vieraat/jhi/Perl/bin:/u/vieraat/vieraat/jhi/.s:/u/vieraat/vieraat/jhi/.b/OSF1:/c/bin:/p/bin:/p/adm/bin:/usr/bin:/usr/sbin:/sbin:/bin:/usr/ccs/bin:/usr/lib:/etc:/lib:/p/X6/bin:/p/X5/bin:/usr/bin/X11:/usr/lbin:/usr/sbin/acct:/usr/tcb/bin:/tcb/bin:/usr/field:/u/vieraat/vieraat/jhi
    PERLLIB=/u/vieraat/vieraat/jhi/Perl/lib
    PERL_BADLANG (unset)
    SHELL=/bin/zsh

From @jhi

Here's the stack trace from the segfault (source code 5_58-to-be at
change #3674 or so, so your linenumbers may be slightly off)​:

signal Segmentation fault at [Perl_av_extend​:143 +0x14,0x3ffbff6d4d4] ary[--tmp] = &PL_sv_undef;

(dbx) list 135,145
  135 newmax = key < 3 ? 3 : key;
  136 New(2,AvALLOC(av), newmax+1, SV*);
  137 ary = AvALLOC(av) + 1;
  138 tmp = newmax;
  139 AvALLOC(av)[0] = &PL_sv_undef; /* For the stacks */
  140 }
  141 if (AvREAL(av)) {
  142 while (tmp)

* 143 ary[--tmp] = &PL_sv_undef;
  144 }
  145

(dbx) p tmp
1073803703
(dbx) p key
1073803704

Hmmm. My bold guess is that the something is using an address as an
array index or something like that. But no more time tonight.

(dbx) where

0 Perl_av_extend(av = 0x14001df18, key = 1073803704) ["av.c"​:143, 0x3ffbff6d4d4]
  1 Perl_av_store(av = 0x14001df18, key = 1073803704, val = 0x14000f078) ["av.c"​:232, 0x3ffbff6d938]
  2 Perl_av_fetch(av = 0x14001df18, key = 1073803704, lval = 1) ["av.c"​:180, 0x3ffbff6d678]
  3 Perl_pp_aelem() ["pp_hot.c"​:2439, 0x3ffbff7aa0c]
  4 Perl_runops_debug() ["run.c"​:57, 0x3ffbff702fc]
  5 S_run_body(args = struct {
  _a0 = 0x11ffff000
  _offset = 24
}) ["perl.c"​:1069, 0x3ffbff09310]
  6 Perl_vdefault_protect(excpt = 0x11ffff050, body = 0x3ffbff090f4, args = 0x11fffefb0) ["scope.c"​:44, 0x3ffbffa67a4]
  7 Perl_default_protect(excpt = 0x11ffff050, body = 0x3ffbff090f4) ["scope.c"​:25, 0x3ffbffa66b0]
  8 perl_run(my_perl = 0x14000e808) ["perl.c"​:1002, 0x3ffbff08e0c]
  9 main(argc = 2, argv = 0x11ffff0a8, env = 0x11ffff0c0) ["perlmain.c"​:53, 0x120002040]

--
$jhi++; # http​://www.iki.fi/jhi/
  # There is this special biologist word we use for 'stable'.
  # It is 'dead'. -- Jack Cohen

From [Unknown Contact. See original ticket]

This changes the symptom from a segfault to "Out of memory!". I
don't claim that this patch is complete, in that I've not checked
to see whether the new key index is validated to fit into an I32
value by the callers of av_extend(). This does fix av_extend
itself not to truncate the value. It might not fix the segfault
for Jarkko, since he built with usemymalloc=y and Ilya's malloc
uses 'int' for the size it passes to sbrk(). It does fix his
test case for 'usemymalloc=n' on my machine.

--- av.c.DIST	Mon Mar 22 15:58:31 1999
+++ av.c	Wed Jul 21 17:28:57 1999
@@ -90,7 +90,8 @@
 	else {
 	    if (AvALLOC(av)) {
 #ifndef STRANGE_MALLOC
-		U32 bytes;
+		MEM_SIZE bytes;
+		IV itmp;
 #endif
 
 #if defined(MYMALLOC) && !defined(PURIFY) && !defined(LEAKTEST)
@@ -106,13 +107,14 @@
 #else
 		bytes = (newmax + 1) * sizeof(SV*);
 #define MALLOC_OVERHEAD 16
-		tmp = MALLOC_OVERHEAD;
-		while (tmp - MALLOC_OVERHEAD < bytes)
-		    tmp += tmp;
-		tmp -= MALLOC_OVERHEAD;
-		tmp /= sizeof(SV*);
-		assert(tmp > newmax);
-		newmax = tmp - 1;
+		itmp = MALLOC_OVERHEAD;
+		while (itmp - MALLOC_OVERHEAD < bytes)
+		    itmp += itmp;
+		itmp -= MALLOC_OVERHEAD;
+		itmp /= sizeof(SV*);
+		assert(itmp > newmax);
+		newmax = itmp - 1;
+		assert(newmax > AvMAX(av));
 		New(2,ary, newmax+1, SV*);
 		Copy(AvALLOC(av), ary, AvMAX(av)+1, SV*);
 		if (AvMAX(av) > 64)

-- 

Spider Boardman (at home) spider@​Orb.Nashua.NH.US
The management (my cats) made me say this.
PGP public key fingerprint​: 96 72 D2 C6 E0 92 32 89 F6 B2 C2 A0 1C AB 1F DC