On Wed, Aug 29, 2012 at 11:24:24AM -0500, Patrick R. Michaud wrote: > On Mon, Aug 27, 2012 at 12:16:08AM +0300, Gabor Szabo wrote: > > After updating Rakudo to the latest and increasing the swap disk to 3 > > Gb I get this Segmentation fault. > > > > /home/gabor/work/rakudo_b/install/bin/parrot --library=src/stage0 > > src/stage0/nqp.pbc \ > > --target=pir --output=src/stage1/gen/nqp-mo.pir \ > > --setting=NULL --no-regex-lib src/stage1/gen/nqp-mo.pm > > make: *** [src/stage1/nqpmo.pbc] Segmentation fault (core dumped) > > FWIW, I'm also occasionally seeing the segfault when compiling > nqp-mo.pm. We'll have to track it down soonish.
My hunch is that the "occasional" is due to the OS having Address Space Layout Randomisation, hence the heap's location varies from invocation to invocation, and sometimes this results in PMCs address that happen to tickle a bad assumption somewhere, possibly in the GC. One way to tell if you have ASLR enabled is to run this a few times: You'll see different addresses on a system with it: $ perl -le "print []" ARRAY(0x1f4bd48) $ perl -le "print []" ARRAY(0xd6fd48) $ perl -le "print []" ARRAY(0xb21d48) But always the same address on a system without it: $ perl -le 'print []' ARRAY(0x100803ed0) $ perl -le "print []" ARRAY(0x100803ed0) $ perl -le "print []" ARRAY(0x100803ed0) To add to the fun, it seems that gdb disables ASLR when you use it to run an executable. So that's not going to be a fruitful way to diagnose it The way to go seems to be `ulimit -c unlimited` and then look at the coredumps that appear. Nicholas Clark
