The first thing after compiling the setting on Rakudo is this:
/home/nicholas/Sandpit/moar-g/bin/moar
--libpath=/home/nicholas/Sandpit/moar-g/languages/nqp/lib perl6.moarvm
--target=mbc --output=lib/Test.moarvm lib/Test.pm
It can SEGV. The problem seems to be that it's writing an i64 (specifically
the value 1), to register 0, which is marked as holding an object. The GC
goes BOOM! if it ever runs:
Starting program: /home/nicholas/Sandpit/moar-g/bin/moar
--libpath=/home/nicholas/Sandpit/moar-g/languages/nqp/lib perl6.moarvm
--target=mbc --output=lib/Test.moarvm lib/Test.pm
[Thread debugging using libthread_db enabled]
Breakpoint 1, MVM_interp_run (tc=0x6023f0,
initial_invoke=0x7ffff7a2e4c8 <toplevel_initial_invoke>,
invoke_data=0x667cf0) at src/core/interp.c:3529
3529 GET_REG(cur_op, 0).i64 = ++tc->sc_wb_disable_depth;
(gdb) p *((MVMuint16 *)(cur_op + 0))
$15 = 0
(gdb) p reg_base[0].i64
$16 = 6348560
(gdb) p frame->static_info->body.local_types[0]
$17 = 8
(gdb) s
3530 cur_op += 2;
(gdb) p reg_base[0].i64
$18 = 1
(gdb) s
3531 goto NEXT;
(gdb)
74 MVMFrame *const frame = tc->cur_frame;
Line numbers might be out as I have some debugging code to make the runloop
abort immediately if any registers holding objects point to fromspace, and
SEGV immediately if any registers holding objects are bad pointers.
And at line 74, register 0, marked as being of type object (8) is actually
holding the value 1, as set by this code:
OP(scwbdisable):
GET_REG(cur_op, 0).i64 = ++tc->sc_wb_disable_depth;
cur_op += 2;
goto NEXT;
I don't know how to debug this further.
Nicholas Clark
