[Vm-dev] Debugging VM crash, INVALID RECEIVER / a(n) bad class ??

[Mariano Martinez Peck]

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:40444*
*40444 && (((longAt(fieldOop)) & MarkBit) != 0)) {*
*(gdb) call printAllStacks()*
*Process 0x30e228c4 priority 40*
*0xbffb2e10 M FaAction class>block: 0x20ebb104: a(n) FaAction class*
*0xbffb2e30 M BlockClosure(FaMemoryStoreSession)>register: 0x371d0968: a(n)
BlockClosure*
*0xbffb2e4c M INVALID RECEIVER>register: 0x371cfd54: a(n) bad class*

*(callerContextOrNil == (nilObject())) || (isContext(callerContextOrNil))
48626*
*0x3721e1f0 is not a context*
*0x371c34b4 is not a context*

And 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:40444*
*40444 && (((longAt(fieldOop)) & MarkBit) != 0)) {*
*(gdb) call printAllStacks()*
*Process 0x30e228c4 priority 40*
*0xbffb2de0 M INVALID RECEIVER>initialize 0x3722b9a0: a(n) bad class*
*0xbffb2df8 M FaAction class(Behavior)>new 0x20ebb104: a(n) FaAction class*
*0xbffb2e10 M FaAction class>block: 0x20ebb104: a(n) FaAction class*
*0xbffb2e30 M INVALID RECEIVER>register: 0x371ddee0: a(n) bad class*
*0xbffb2e4c M INVALID RECEIVER>register: 0x371dd328 is in old space*

*(callerContextOrNil == (nilObject())) || (isContext(callerContextOrNil))
48626*
*0x3722b750 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: maybeMessage*
It 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)) 40416*


Any pointer is appreciated.

Thanks!

-- 
Mariano
http://marianopeck.wordpress.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20151116/40958cf8/attachment.htm