From @dogbert17

# the system, 32 bit Linux vm running under VirtualBox
dogbert@​dogbert-VirtualBox ~ $ cat /etc/os-release
NAME="Ubuntu"
VERSION="14.04.3 LTS, Trusty Tahr"
ID=ubuntu
ID_LIKE=debian
PRETTY_NAME="Ubuntu 14.04.3 LTS"
VERSION_ID="14.04"
HOME_URL="http://www.ubuntu.com/"
SUPPORT_URL="http://help.ubuntu.com/"
BUG_REPORT_URL=http://bugs.launchpad.net/ubuntu/

dogbert@​dogbert-VirtualBox ~ $ perl6 -v
This is Rakudo version 2016.11-149-g5bacb0573 built on MoarVM version
2016.11-36-g2c50886b
implementing Perl 6.c.

# the problem
# run the following script (tried to golf more), I call it scratch.pl6
# https://gist.github.com/dogbert17/41042137f44394a0094c1cc1c05055bb
Running the code results in a SEGV

AlexDaniel did a quick bisect with the bisectbot and uncovered the following
commit as a likely suspect​:
rakudo/rakudo@172898e
146d

/dogbert17

From @coke

Attaching gistfile to ticket

--
Will "Coke" Coleda

From @coke

use v6;
my $size = 3001;
my int @​mat[$size; $size];

init-array(0, $size - 1, $size * $size);
say 'done';
sub init-array($r, $c, $val) {
  @​mat[$r; $c] = $val;
  if $c - 1 >= 0
  { # left
  init-array($r, $c - 1, $val - 1);
  }
  elsif $r + 1 < $size
  { # down
  init-array($r + 1, $c, $val - 1);
  }
}

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

From @lizmat

Confirmed on macOS.

Running with MVM_SPESH_DISABLE=1 does not prevent the segv.

Running with —optimize=0 and —optimize=1 *does* prevent the issue. —optimize=2 and higher shows the problem.

Running with “use trace” shows a *lot* of output​: the last lines shown are​:

12 (/Users/liz/Github/rakudo.moar/1 line 13)
@​mat[$r; $c] = $val
13 (/Users/liz/Github/rakudo.moar/1 line 13)
$r
14 (/Users/liz/Github/rakudo.moar/1 line 13)
$c

So it looks like evaluating $c does it? Feels like some kind of memory corruption to me.

On 20 Dec 2016, at 16​:16, Will Coleda via RT <perl6-bugs-followup@​perl.org> wrote​:

Attaching gistfile to ticket

--
Will "Coke" Coleda
use v6;
my $size = 3001;
my int @​mat[$size; $size];

init-array(0, $size - 1, $size * $size);
say 'done';
sub init-array($r, $c, $val) {
@​mat[$r; $c] = $val;
if $c - 1 >= 0
{ # left
init-array($r, $c - 1, $val - 1);
}
elsif $r + 1 < $size
{ # down
init-array($r + 1, $c, $val - 1);
}
}

From lucasbuchala@gmail.com

Hi. I narrowed the code to this snippet, I hope it helps. It segfault
in my x86 32bit machine.
The subroutine below is nonsensical and should be an infinite
recursion, but it triggers the segfault bug and halts the program.
So, if this doesn't trigger the segfault in your machine, remember to
type Ctrl+C to abort the program.

my int @​a[1];

sub f($i) {

  @​a[0];

  print "$i ";

  if $i { f($i-1) }
  elsif !$i { f($i-1) }
}

f(839);

From @jnthn

On Wed, 07 Dec 2016 14​:33​:54 -0800, jan-olof.hendig@​bredband.net wrote​:

# the system, 32 bit Linux vm running under VirtualBox
dogbert@​dogbert-VirtualBox ~ $ cat /etc/os-release
NAME="Ubuntu"
VERSION="14.04.3 LTS, Trusty Tahr"
ID=ubuntu
ID_LIKE=debian
PRETTY_NAME="Ubuntu 14.04.3 LTS"
VERSION_ID="14.04"
HOME_URL="http://www.ubuntu.com/"
SUPPORT_URL="http://help.ubuntu.com/"
BUG_REPORT_URL=http://bugs.launchpad.net/ubuntu/

dogbert@​dogbert-VirtualBox ~ $ perl6 -v
This is Rakudo version 2016.11-149-g5bacb0573 built on MoarVM version
2016.11-36-g2c50886b
implementing Perl 6.c.

# the problem
# run the following script (tried to golf more), I call it scratch.pl6
# https://gist.github.com/dogbert17/41042137f44394a0094c1cc1c05055bb
Running the code results in a SEGV

AlexDaniel did a quick bisect with the bisectbot and uncovered the following
commit as a likely suspect​:
rakudo/rakudo@172898e
146d

It managed to look like both a GC bug and an inlining bug in MoarVM, but actually ended up being a boring callstack region overflow bug that affected some (and only some) heavily recursive code. It's fixed now, and there's a test to cover it in integration/deep-recursion-initing-native-array.t.

/jnthn

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