Problem running programs on RPi with 2018.08

[dogbert17]

There seems to be a problem running Perl 6 programs on RPi (2) using 2018.08. Many small snippets and spectest files SEGV's and the only way to avoid this is to set MVM_SPESH_DISABLE=1. Neither MVM_SPESH_INLINE_DISABLE=1 nor MVM_SPESH_OSR_DISABLE=1 does resolve the problem. In fact, it wasn't even posssible to build 2018.08 unless MVM_SPESH_DISABLE=1 was set.

As far as I have seen, the SEGV backtrace, see below, always look the same.

pi@raspberrypi:~/repos/rakudo $ cat /etc/os-release 
PRETTY_NAME="Raspbian GNU/Linux 8 (jessie)"
NAME="Raspbian GNU/Linux"
VERSION_ID="8"
VERSION="8 (jessie)"
ID=raspbian
ID_LIKE=debian
HOME_URL="http://www.raspbian.org/"
SUPPORT_URL="http://www.raspbian.org/RaspbianForums"
BUG_REPORT_URL="http://www.raspbian.org/RaspbianBugs"

pi@raspberrypi:~/repos/rakudo $ cat ~/euler-4.pl6 
# Find the largest palindrome made from the product of two 3-digit numbers
use v6;
my $high = 999;
my $low = 100;
my $maxval = 0;
for ($low..$high).reverse -> $x {
  last if $x * $x < $maxval;
  for ($low..$x).reverse -> $y {
    my $prod = $x * $y;
    $maxval = $prod if $prod.flip eq $prod && $prod > $maxval;
  }
}
say $maxval;

pi@raspberrypi:~/repos/rakudo $ ./perl6-gdb-m ~/euler-4.pl6 
================================================================================================
This is Rakudo Perl 6 running in the GNU debugger, which often allows the user to generate useful back-
traces to debug or report issues in Rakudo, the MoarVM backend or the currently running code.

This Rakudo version is 2018.08.30.g.5.b.34.f.69 built on MoarVM version 2018.08.21.gccc.315.f,
running on raspbian (8.jessie) / linux (4.1.19.v.7+)

Type `bt full` to generate a backtrace if applicable, type `q` to quit or `help` for help.
------------------------------------------------------------------------------------------------
Reading symbols from /home/pi/repos/rakudo/install/bin/moar...done.
Starting program: /home/pi/repos/rakudo/install/bin/moar --execname=./perl6-gdb-m --libpath=. --libpath=blib --libpath=/home/pi/repos/rakudo/install/share/nqp/lib --libpath=/home/pi/repos/rakudo/install/share/nqp/lib --libpath=/home/pi/repos/rakudo/install/share/nqp/lib /home/pi/repos/rakudo/perl6.moarvm --nqp-lib=blib /home/pi/euler-4.pl6
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/arm-linux-gnueabihf/libthread_db.so.1".
[New Thread 0x7631d460 (LWP 11429)]

Program received signal SIGSEGV, Segmentation fault.
0x76abfe18 in MVM_gc_collect_free_nursery_uncopied (tc=0x23668, limit=0x76780ff4) at src/gc/collect.c:607
607	            if (dead && REPR(obj)->gc_free)
(gdb) p dead
$1 = 1 '\001'
(gdb) p REPR(obj)
Cannot access memory at address 0xc
(gdb) bt
#0  0x76abfe18 in MVM_gc_collect_free_nursery_uncopied (tc=0x23668, limit=0x76780ff4) at src/gc/collect.c:607
#1  0x76ab7b04 in finish_gc (tc=0x23668, gen=0 '\000', is_coordinator=1 '\001') at src/gc/orchestrate.c:241
#2  0x76ab8148 in run_gc (tc=0x23668, what_to_do=0 '\000') at src/gc/orchestrate.c:413
#3  0x76ab856c in MVM_gc_enter_from_allocator (tc=0x23668) at src/gc/orchestrate.c:526
#4  0x76ab8f34 in MVM_gc_allocate_nursery (tc=0x23668, size=24) at src/gc/allocation.c:32
#5  0x76ab8cc0 in MVM_gc_allocate (tc=0x23668, size=24) at src/gc/allocation.h:18
#6  0x76ab8fd8 in MVM_gc_allocate_zeroed (tc=0x23668, size=24) at src/gc/allocation.c:49
#7  0x76ab91c4 in MVM_gc_allocate_object (tc=0x23668, st=0x552fd0) at src/gc/allocation.c:86
#8  0x76aed5b8 in allocate (tc=0x23668, st=0x552fd0) at src/6model/reprs/P6opaque.c:60
#9  0x76a951b8 in MVM_box_str (tc=0x23668, value=0x735f8730, type=0x554108, dst=0x2198500) at src/core/coerce.c:519
#10 0x76a61984 in MVM_interp_run (tc=0x23668, initial_invoke=0x76c63d04 <toplevel_initial_invoke>, invoke_data=0x9dfc8) at src/core/interp.c:2124
#11 0x76c63e58 in MVM_vm_run_file (instance=0x23008, filename=0x7efff78b "/home/pi/repos/rakudo/perl6.moarvm") at src/moar.c:420
#12 0x000114ac in main (argc=10, argv=0x7efff534) at src/main.c:300
(gdb) info threads
  Id   Target Id         Frame 
  2    Thread 0x7631d460 (LWP 11429) "moar" 0x767b77a4 in __pthread_cond_wait (cond=0x9cbf0, mutex=0x9cbc0) at pthread_cond_wait.c:187
* 1    Thread 0x76ff6000 (LWP 11426) "moar" 0x76abfe18 in MVM_gc_collect_free_nursery_uncopied (tc=0x23668, limit=0x76780ff4) at src/gc/collect.c:607
(gdb) p MVM_dump_backtrace(tc)
   at <unknown>:1  (<ephemeral file>:)
 from <unknown>:1  (<ephemeral file>:)
 from /home/pi/euler-4.pl6:10  (<ephemeral file>:<unit>)
 from /home/pi/euler-4.pl6:1  (<ephemeral file>:<unit-outer>)
 from gen/moar/stage2/NQPHLL.nqp:1567  (/home/pi/repos/rakudo/install/share/nqp/lib/NQPHLL.moarvm:eval)
 from gen/moar/stage2/NQPHLL.nqp:1806  (/home/pi/repos/rakudo/install/share/nqp/lib/NQPHLL.moarvm:evalfiles)
 from gen/moar/stage2/NQPHLL.nqp:1696  (/home/pi/repos/rakudo/install/share/nqp/lib/NQPHLL.moarvm:command_eval)
 from src/Perl6/Compiler.nqp:42  (blib/Perl6/Compiler.moarvm:command_eval)
 from gen/moar/stage2/NQPHLL.nqp:1655  (/home/pi/repos/rakudo/install/share/nqp/lib/NQPHLL.moarvm:command_line)
 from gen/moar/main.nqp:47  (/home/pi/repos/rakudo/perl6.moarvm:MAIN)
 from gen/moar/main.nqp:38  (/home/pi/repos/rakudo/perl6.moarvm:<mainline>)
 from <unknown>:1  (/home/pi/repos/rakudo/perl6.moarvm:<main>)
 from <unknown>:1  (/home/pi/repos/rakudo/perl6.moarvm:<entry>)
$2 = void
(gdb) q

[AlexDaniel]

@dogbert17 can you bisect it?

[dogbert17]

Not sure if I can bisect it. Building times on RPi are very long. I can add that 2018.06 works without any issues though.

[robertlemmen]

bisecting shows that the problem appears with rakudo commit a6edf511d8209, bisecting into the moar commits that this brought in indicates the problem is in 67a9afe.

looking at that change, the only effective difference is the usage of MVM_ALIGN_SIZE in MVM_gc_allocate(), called by MVM_gc_allocate_zeroed(), which the new version does not have. this kinda fits the general symptom of this only happening on armhf, because that arch has strict alignment requirements. this is where my understanding ends though, I would understand a SIGBUS or so, but the stacktraces show memory corruption....

To test this theory I added a size = MVM_ALIGN_SIZE(size); at the top of MVM_gc_allocate_nursery(), and the problem goes away, the euler-4.pl6 case from above now works.