On Sun, Dec 15, 2013 at 08:50:27PM +0000, Nicholas Clark wrote:
> On Sun, Dec 15, 2013 at 05:56:40PM +0000, Nicholas Clark wrote:
>
> > With this, all NQP tests pass I can build the Rakudo setting, with a nursery
> > size of 2048K.
> >
> > I have now written a script that will attempt to repeatedly recompile that
> > far, each time dropping the nursery size by 1K, until something breaks.
> > I shall nice it appropriately, and if it still going tomorrow, try again
> > with a larger decrement, until something does fail.
>
> Hit at 2047.
Edited it to carry on with just NQP, and got a hit at 2013.
Starting program: /home/nicholas/Sandpit/burndown1/bin/moar
--libpath=src/vm/moar/stage0 src/vm/moar/stage0/nqp.moarvm --bootstrap
--module-path=gen/moar/stage1 --setting-path=gen/moar/stage1 --setting=NQPCORE
--target=mbc --no-regex-lib --output=gen/moar/stage1/nqp.moarvm
gen/moar/stage1/NQP.nqp[Thread debugging using libthread_db enabled]
Program received signal SIGSEGV, Segmentation fault.
0x00007ffff79c7308 in run_load (tc=0x6023f0, sr_data=0x7ffff6a42e38)
at src/core/loadbytecode.c:109
109 if (cu->body.load_frame) {
Missing separate debuginfos, use: debuginfo-install glibc-2.12-1.107.el6.x86_64
(gdb) p cu
$1 = (MVMCompUnit *) 0x7ffff6a42e38
(gdb) p tc->nursery_fromspace
$2 = (void *) 0x7ffff68a2000
(gdb) p tc->nursery_tospace
$3 = (void *) 0x7ffff6a9a000
(gdb) where
#0 0x00007ffff79c7308 in run_load (tc=0x6023f0, sr_data=0x7ffff6a42e38)
at src/core/loadbytecode.c:109
#1 0x00007ffff79b707b in return_or_unwind (tc=0x6023f0, unwind=0 '\000')
at src/core/frame.c:341
#2 0x00007ffff79b70d2 in MVM_frame_try_return (tc=0x6023f0)
at src/core/frame.c:362
#3 0x00007ffff7998d7d in MVM_interp_run (tc=0x6023f0,
initial_invoke=0x7ffff7a2fac3 <toplevel_initial_invoke>,
invoke_data=0x74f570) at src/core/interp.c:279
#4 0x00007ffff7a2fbf0 in MVM_vm_run_file (instance=0x602010,
filename=0x7fffffffe76d "src/vm/moar/stage0/nqp.moarvm") at src/moar.c:157
#5 0x0000000000400d2e in main (argc=11, argv=0x7fffffffe498) at src/main.c:137
It look like the stored value caller->special_return_data got moved:
/* Switch back to the caller frame if there is one. */
if (caller && returner != tc->thread_entry_frame) {
tc->cur_frame = caller;
*(tc->interp_cur_op) = caller->return_address;
*(tc->interp_bytecode_start) = caller->static_info->body.bytecode;
*(tc->interp_reg_base) = caller->work;
*(tc->interp_cu) = caller->static_info->body.cu;
/* Handle any special return hooks. */
if (caller->special_return) {
MVMSpecialReturn sr = caller->special_return;
caller->special_return = NULL;
if (!unwind)
sr(tc, caller->special_return_data);
}
Again, I don't know what the fix should be, but having read the GC talk
slides, my hunch is that it's "you can't be storing unpinned things in a
C struct".
Nicholas Clark
