On Mon, Nov 16, 2015 at 1:07 PM, Nicolai Hess <nicolaihess@gmail.com> wrote:��maybe this issue is responsible - wrong stack frame size :Hi Mariano, if you know the method that may cause this crash can you checkif it works if you recompile this method with the old compiler,
13854 frameSize calculated wrongly for #lineSegmentsDo:Hi Nicolai,Thanks for the pointer. I tried with your fix and I still get the same results (even after recompiling).However...if I swap back to old Compiler rather than OpalCompiler and I recompile everything, then I do not have anymore the crash.��So it's definitively something related to Opal compilation, and probably, related to closures compilation.��I will see if I find other opal issues opened in 4.0.Thanks!��2015-11-16 17:00 GMT+01:00 Mariano Martinez Peck <marianopeck@gmail.com>:��Hi guys,I am debugging a Pharo VM crash I am having and I cannot figure out what it is exactly. I suspect it might be related to block closures compilation but I am not sure. I have a reproducible crash test under Pharo 4.0 and OSX.��I built a VM in debug mode and I run it via gdb. This is the kind of info I am able to see:Program received signal SIGSEGV, Segmentation fault.0x000ab66b in updatePointersInRangeFromto (memStart=924623948, memEnd=928201420) at /Users/mariano/Pharo/git/pharo-vm/src/vm/gcc3x-cointerp.c:4044440444 && (((longAt(fieldOop)) & MarkBit) != 0)) {(gdb) call printAllStacks()Process 0x30e228c4 priority 400xbffb2e10 M FaAction class>block: 0x20ebb104: a(n) FaAction class0xbffb2e30 M BlockClosure(FaMemoryStoreSession)>register: 0x371d0968: a(n) BlockClosure0xbffb2e4c M INVALID RECEIVER>register: 0x371cfd54: a(n) bad class(callerContextOrNil == (nilObject())) || (isContext(callerContextOrNil)) 486260x3721e1f0 is not a context0x371c34b4 is not a contextAnd another crash:Program received signal SIGSEGV, Segmentation fault.0x000ab66b in updatePointersInRangeFromto (memStart=924677864, memEnd=928262300) at /Users/mariano/Pharo/git/pharo-vm/src/vm/gcc3x-cointerp.c:4044440444 && (((longAt(fieldOop)) & MarkBit) != 0)) {(gdb) call printAllStacks()Process 0x30e228c4 priority 400xbffb2de0 M INVALID RECEIVER>initialize 0x3722b9a0: a(n) bad class0xbffb2df8 M FaAction class(Behavior)>new 0x20ebb104: a(n) FaAction class0xbffb2e10 M FaAction class>block: 0x20ebb104: a(n) FaAction class0xbffb2e30 M INVALID RECEIVER>register: 0x371ddee0: a(n) bad class0xbffb2e4c M INVALID RECEIVER>register: 0x371dd328 is in old space(callerContextOrNil == (nilObject())) || (isContext(callerContextOrNil)) 486260x3722b750 is not a context[New Thread 0x1b43 of process 5886][New Thread 0x1d2f of process 5886][New Thread 0x1f07 of process 5886][New Thread 0x1e07 of process 5886]From what I can see in #printActivationNameFor: aMethod receiver: anObject isBlock: isBlock firstTemporary: maybeMessageIt looks like if the memory address is not an OOP, nor forwarding pointer nor...It also seems like the above stack I can get is not the real cause but a side effect that makes GC to crash (#updatePointersInRangeFromto)As said, I have a way to reproduce the crash, and I already have the VM compiled in debug and gdb running. I can also attach the full output of the gdb stack.��BTW.... in the output of the gdb I see lots of printings like:(numStack + ReceiverIndex) < (lengthOf(theContext)) 45421(ReceiverIndex + contextSize) < (lengthOfbaseHeaderformat(oop, header2, fmt)) 40416Any pointer is appreciated.Thanks!--
--