On Mon, Nov 16, 2015 at 5:37 PM, Mariano Martinez Peck < marianopeck@gmail.com> wrote:
Hi guys,
So I found out the exact method that is causing the VM crash. If I compile the method with Opal, it crashes the VM when I execute the code that use that method. If I compile it with old compiler, the code does work correctly.
I tried comparing both compiled methods compiled from both Compilers and I cannot see real differences. They both seem to have similar (same?) bytecodes, literals, decompiled string, etc. The only difference I see is in #frameSize (old compiler one is 16 while Opal one is 56). Any idea what else can I check/compare?
I also tried in Pharo 5.0 but same results.
Thanks in advance,
OK, it seems my issue may be related to: https://pharo.fogbugz.com/f/cases/13854/frameSize-calculated-wrongly-for-lin... But the attached cs in there does NOT fixes mine. I can confirm it's a problem with the number of temp vars defined. As soon as I remove any of the temp vars, it works again. The method is this (a bit ugly, yes) pasted below. But the key point is: *As soon as I remove ANY tempVar the code starts to work again.* Any clues? createZacksAccountingRulesFromTable: t1 | t2 t3 t4 | t2 := FaUserContextInformation current dbAccessor db: 'zacks' getTableAccessorOn: t1 indexOn: nil. t3 := OrderedCollection new. t4 := FaFileTranscript named: 'create-zacks-rules.txt'. FaApplicationDB session inUnitOfWorkDo: [:t5 | | t6 | t6 := FaUserContextInformation current userDisplayName. t2 doWithRowDictionaries: [:t7 | (t7 at: 'label') == FaNullDatum instance ifFalse: [{{'Annual'. 'ZACKS_A_'}. {'Quarterly'. 'ZACKS_Q_'}} do: [:t8 | *| t9 t10 t11 t12 t13 t14 t15 t16 t17 t18 |* t4 crLog: t8 first. t9 := t8 at: 1. t16 := t7 at: 'label'. t18 := t7 at: 'TTM'. t10 := t7 at: 'quuveKeyEquivalent'. t12 := (t7 at: 'zacksKey') asUppercase. t13 := 'ZACKS_' , t12. t14 := 'ZACKS_Q_' , t12. t15 := 'ZACKS_A_' , t12. t11 := (t8 at: 2) , t12. t17 := FaAccountingRule new label: t16; selector: t13 asSymbol; context: 'Zacks' , t9 , 'Override'; argumentTypesSpecification: '{FaProcessorProxy}'; returnTypeSpecification: 'FaDatedFnSeries'; isReturnValueConstant: true; action: (self getZacksDataAtScriptForCache: t11 forZacksKey: t11 fromSet: t9); comment: (nil ifNil: [t16]); isSensitive: true; definedBy: t6; ownedBy: t6; lastEditBy: t6; yourself. t5 register: t17. t3 add: 'Successfully added ' , t17 selector , '/' , t17 context. t4 crLog: t3 last]]]]. ^ t3
On Mon, Nov 16, 2015 at 2:48 PM, Mariano Martinez Peck < marianopeck@gmail.com> wrote:
On Mon, Nov 16, 2015 at 2:48 PM, Mariano Martinez Peck < marianopeck@gmail.com> wrote:
On Mon, Nov 16, 2015 at 1:07 PM, Nicolai Hess <nicolaihess@gmail.com> wrote:
Hi Mariano, if you know the method that may cause this crash can you check if it works if you recompile this method with the old compiler, maybe this issue is responsible - wrong stack frame size : 13854 <https://pharo.fogbugz.com/f/cases/13854/frameSize-calculated-wrongly-for-lin...> 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: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
-- Mariano http://marianopeck.wordpress.com
-- Mariano http://marianopeck.wordpress.com
-- Mariano http://marianopeck.wordpress.com
-- Mariano http://marianopeck.wordpress.com