From @andk

git bisect

e8eb279 is the first bad commit
commit e8eb279
Author​: Father Chrysostomos <sprout@​cpan.org>
Date​: Sat Aug 24 18​:02​:09 2013 -0700

  Use SSize_t for tmps stack offsets

  This is a partial fix for #119161.

  On 64-bit platforms, I32 is too small to hold offsets into a stack
  that can grow larger than I32_MAX. What happens is the offsets can
  wrap so we end up referencing and modifying elements with negative
  indices, corrupting memory, and causing crashes.

  With this commit, ()=1..1000000000000 stops crashing immediately.
  Instead, it gobbles up all your memory first, and then, if your com-
  puter still survives, crashes. The second crash happesn bcause of
  a similar bug with the argument stack, which the next commit will
  take care of.

diagnostics

http​://www.cpantesters.org/cpan/report/f43d6962-cf48-11e3-a383-9294310f0ce5

perl -V

Summary of my perl5 (revision 5 version 19 subversion 4) configuration​:
  Commit id​: 388a7a8
  Platform​:
  osname=linux, osvers=3.13-1-amd64, archname=x86_64-linux-thread-multi
  uname='linux k83 3.13-1-amd64 #1 smp debian 3.13.7-1 (2014-03-25) x86_64 gnulinux '
  config_args='-Dprefix=/home/sand/src/perl/repoperls/installed-perls/perl/v5.19.4/9980 -Dmyhostname=k83 -Dinstallusrbinperl=n -Uversiononly -Dusedevel -des -Ui_db -Duseithreads -Uuselongdouble -DDEBUGGING=-g'
  hint=recommended, useposix=true, d_sigaction=define
  useithreads=define, usemultiplicity=define
  useperlio=define, d_sfio=undef, uselargefiles=define, usesocks=undef
  use64bitint=define, use64bitall=define, uselongdouble=undef
  usemymalloc=n, bincompat5005=undef
  Compiler​:
  cc='cc', ccflags ='-D_REENTRANT -D_GNU_SOURCE -fno-strict-aliasing -pipe -fstack-protector -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64',
  optimize='-O2 -g',
  cppflags='-D_REENTRANT -D_GNU_SOURCE -fno-strict-aliasing -pipe -fstack-protector -I/usr/local/include'
  ccversion='', gccversion='4.8.2', gccosandvers=''
  intsize=4, longsize=8, ptrsize=8, doublesize=8, byteorder=12345678
  d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=16
  ivtype='long', ivsize=8, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=8
  alignbytes=8, prototype=define
  Linker and Libraries​:
  ld='cc', ldflags =' -fstack-protector -L/usr/local/lib'
  libpth=/usr/local/lib /lib/x86_64-linux-gnu /lib/../lib /usr/lib/x86_64-linux-gnu /usr/lib/../lib /lib /usr/lib
  libs=-lnsl -lgdbm -ldb -ldl -lm -lcrypt -lutil -lpthread -lc -lgdbm_compat
  perllibs=-lnsl -ldl -lm -lcrypt -lutil -lpthread -lc
  libc=, so=so, useshrplib=false, libperl=libperl.a
  gnulibc_version='2.18'
  Dynamic Linking​:
  dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-Wl,-E'
  cccdlflags='-fPIC', lddlflags='-shared -O2 -g -L/usr/local/lib -fstack-protector'

Characteristics of this binary (from libperl)​:
  Compile-time options​: HAS_TIMES MULTIPLICITY PERLIO_LAYERS
  PERL_DONT_CREATE_GVSV
  PERL_HASH_FUNC_ONE_AT_A_TIME_HARD
  PERL_IMPLICIT_CONTEXT PERL_MALLOC_WRAP
  PERL_NEW_COPY_ON_WRITE PERL_PRESERVE_IVUV
  PERL_USE_DEVEL USE_64_BIT_ALL USE_64_BIT_INT
  USE_ITHREADS USE_LARGE_FILES USE_LOCALE
  USE_LOCALE_COLLATE USE_LOCALE_CTYPE
  USE_LOCALE_NUMERIC USE_PERLIO USE_PERL_ATOF
  USE_REENTRANT_API
  Built under linux
  Compiled at Apr 29 2014 04​:19​:55
  %ENV​:
  PERL5LIB=""
  PERL5OPT=""
  PERL5_CPANPLUS_IS_RUNNING="28938"
  PERL5_CPAN_IS_RUNNING="28938"
  @​INC​:
  /home/sand/src/perl/repoperls/installed-perls/perl/v5.19.4/9980/lib/site_perl/5.19.4/x86_64-linux-thread-multi
  /home/sand/src/perl/repoperls/installed-perls/perl/v5.19.4/9980/lib/site_perl/5.19.4
  /home/sand/src/perl/repoperls/installed-perls/perl/v5.19.4/9980/lib/5.19.4/x86_64-linux-thread-multi
  /home/sand/src/perl/repoperls/installed-perls/perl/v5.19.4/9980/lib/5.19.4
  .

--
andreas

From @iabyn

On Tue, Apr 29, 2014 at 08​:34​:29PM -0700, Andreas J. Koenig via RT wrote​:

# New Ticket Created by (Andreas J. Koenig)
# Please include the string​: [perl #121767]
# in the subject line of all future correspondence about this issue.
# <URL​: https://rt-archive.perl.org/perl5/Ticket/Display.html?id=121767 >

git bisect
----------
e8eb279 is the first bad commit
commit e8eb279
Author​: Father Chrysostomos <sprout@​cpan.org>
Date​: Sat Aug 24 18​:02​:09 2013 -0700

Use SSize\_t for tmps stack offsets

This is a partial fix for \#119161\.

On 64\-bit platforms\, I32 is too small to hold offsets into a stack
that can grow larger than I32\_MAX\.  What happens is the offsets can
wrap so we end up referencing and modifying elements with negative
indices\, corrupting memory\, and causing crashes\.

With this commit\, \(\)=1\.\.1000000000000 stops crashing immediately\.
Instead\, it gobbles up all your memory first\, and then\, if your com\-
puter still survives\, crashes\.  The second crash happesn bcause of
a similar bug with the argument stack\, which the next commit will
take care of\.

This is because Coro declares a structure that mimics a perl interpreter
struct (but with fewer members), and which has tmps_ix etc fields.
Since the type has changed in perl (from 32-bit to 64-bit), Coro needs to
do something similar.

With this diff​:

-6.37-/Coro/state.h Coro-6.37/Coro/state.h

--- Coro-6.37-/Coro/state.h	2012-02-20 07:51:30.000000000 +0000
+++ Coro-6.37/Coro/state.h	2014-04-30 14:31:15.952377627 +0100
@@ -37,9 +37,9 @@
 VAR(savestack_max, I32)
 
 VAR(tmps_stack,    SV **)          /* mortals we've made */
-VAR(tmps_ix,       I32)
-VAR(tmps_floor,    I32)
-VAR(tmps_max,      I32)
+VAR(tmps_ix,       SSize_t)
+VAR(tmps_floor,    SSize_t)
+VAR(tmps_max,      SSize_t)
 
 VAR(markstack,     I32 *)          /* stack_sp locations we're remembering */
 VAR(markstack_p

As for the t/19_handle.t SEGV, slf_init_rw() in Ev.xs is trying to
use element 5 of a passed array (which I think is a Coro​::Handle​::FH
object), and that element is a NULL pointer. I haven't looked at that in
any more detail.

--
"Foul and greedy Dwarf - you have eaten the last candle."
  -- "Hordes of the Things", BBC Radio.

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

From @rjbs

This was corrected in 6.39.

--
rjbs

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