November 2015 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Opal problem causing crash but old compiler works [WAS] Re: [Vm-dev] Debugging VM crash, INVALID RECEIVER / a(n) bad class ??

by Nicolai Hess

2015-11-17 1:35 GMT+01:00 Mariano Martinez Peck <marianopeck(a)gmail.com>: > > > On Mon, Nov 16, 2015 at 8:41 PM, Nicolai Hess <nicolaihess(a)gmail.com> > wrote: > >> >> >> 2015-11-16 22:16 GMT+01:00 Mariano Martinez Peck <marianopeck(a)gmail.com>: >> >>> >>> >>> On Mon, Nov 16, 2015 at 5:37 PM, Mariano Martinez Peck < >>> marianopeck(a)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-li… >>> But the attached cs in there does NOT fixes mine. >>> >> >> You need to: >> switch to old compiler in settings >> > > I was doing that via > > Smalltalk compilerClass: XXX. > > (I didn't know there was setting). > > >> load change set fix_closure_stack_frame_size_computation.1.cs (not >> fix_closure_stack_frame_size_computation.2.cs!) >> switch back to opal >> recompile all >> > > Yes, I did that. > > >> But the change set is old, and does not work for recent images (not even >> for pharo 4.0 release), because there are many >> changes for the bytecodegenerator. >> > > Uhhhh. Yes, I saw some. For example, i changed from > IRAbstractBytecodeGenerator to IRBytecodeGenerator > > Do you think we can re-create your fix with latest 4.0 or 5.0 so that I > can see if the issue was the same? > you can try this one, (I just changed all the code that makes this run for pharo 4, but I need more time to check if all of this code is necessary - and correct) : fix_closure_stack_size_4.0.cs (tested with Pharo 4.0 40624). > > > >> >> >> >>> 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(a)gmail.com> wrote: >>>> >>>>> >>>>> >>>>> On Mon, Nov 16, 2015 at 2:48 PM, Mariano Martinez Peck < >>>>> marianopeck(a)gmail.com> wrote: >>>>> >>>>>> >>>>>> >>>>>> On Mon, Nov 16, 2015 at 1:07 PM, Nicolai Hess <nicolaihess(a)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-li…> >>>>>>> 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(a)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 >>> >> >> > > > -- > Mariano > http://marianopeck.wordpress.com >

Nov. 17, 2015

Re: [Pharo-dev] Opal problem causing crash but old compiler works [WAS] Re: [Vm-dev] Debugging VM crash, INVALID RECEIVER / a(n) bad class ??

by Mariano Martinez Peck

On Mon, Nov 16, 2015 at 8:41 PM, Nicolai Hess <nicolaihess(a)gmail.com> wrote: > > > 2015-11-16 22:16 GMT+01:00 Mariano Martinez Peck <marianopeck(a)gmail.com>: > >> >> >> On Mon, Nov 16, 2015 at 5:37 PM, Mariano Martinez Peck < >> marianopeck(a)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-li… >> But the attached cs in there does NOT fixes mine. >> > > You need to: > switch to old compiler in settings > I was doing that via Smalltalk compilerClass: XXX. (I didn't know there was setting). > load change set fix_closure_stack_frame_size_computation.1.cs (not > fix_closure_stack_frame_size_computation.2.cs!) > switch back to opal > recompile all > Yes, I did that. > But the change set is old, and does not work for recent images (not even > for pharo 4.0 release), because there are many > changes for the bytecodegenerator. > Uhhhh. Yes, I saw some. For example, i changed from IRAbstractBytecodeGenerator to IRBytecodeGenerator Do you think we can re-create your fix with latest 4.0 or 5.0 so that I can see if the issue was the same? > > > >> 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(a)gmail.com> wrote: >>> >>>> >>>> >>>> On Mon, Nov 16, 2015 at 2:48 PM, Mariano Martinez Peck < >>>> marianopeck(a)gmail.com> wrote: >>>> >>>>> >>>>> >>>>> On Mon, Nov 16, 2015 at 1:07 PM, Nicolai Hess <nicolaihess(a)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-li…> >>>>>> 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(a)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 >> > > -- Mariano http://marianopeck.wordpress.com

Nov. 17, 2015

Re: [Pharo-dev] Opal problem causing crash but old compiler works [WAS] Re: [Vm-dev] Debugging VM crash, INVALID RECEIVER / a(n) bad class ??

by Nicolai Hess

2015-11-16 22:16 GMT+01:00 Mariano Martinez Peck <marianopeck(a)gmail.com>: > > > On Mon, Nov 16, 2015 at 5:37 PM, Mariano Martinez Peck < > marianopeck(a)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-li… > But the attached cs in there does NOT fixes mine. > You need to: switch to old compiler in settings load change set fix_closure_stack_frame_size_computation.1.cs (not fix_closure_stack_frame_size_computation.2.cs!) switch back to opal recompile all But the change set is old, and does not work for recent images (not even for pharo 4.0 release), because there are many changes for the bytecodegenerator. > 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(a)gmail.com> wrote: >> >>> >>> >>> On Mon, Nov 16, 2015 at 2:48 PM, Mariano Martinez Peck < >>> marianopeck(a)gmail.com> wrote: >>> >>>> >>>> >>>> On Mon, Nov 16, 2015 at 1:07 PM, Nicolai Hess <nicolaihess(a)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-li…> >>>>> 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(a)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 >

Nov. 16, 2015

Re: [Pharo-dev] Opal problem causing crash but old compiler works [WAS] Re: [Vm-dev] Debugging VM crash, INVALID RECEIVER / a(n) bad class ??

by Mariano Martinez Peck

On Mon, Nov 16, 2015 at 5:37 PM, Mariano Martinez Peck < marianopeck(a)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-li… 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(a)gmail.com> wrote: > >> >> >> On Mon, Nov 16, 2015 at 2:48 PM, Mariano Martinez Peck < >> marianopeck(a)gmail.com> wrote: >> >>> >>> >>> On Mon, Nov 16, 2015 at 1:07 PM, Nicolai Hess <nicolaihess(a)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-li…> >>>> 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(a)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

Nov. 16, 2015

Opal problem causing crash but old compiler works [WAS] Re: [Vm-dev] Debugging VM crash, INVALID RECEIVER / a(n) bad class ??

by Mariano Martinez Peck

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, On Mon, Nov 16, 2015 at 2:48 PM, Mariano Martinez Peck < marianopeck(a)gmail.com> wrote: > > > On Mon, Nov 16, 2015 at 2:48 PM, Mariano Martinez Peck < > marianopeck(a)gmail.com> wrote: > >> >> >> On Mon, Nov 16, 2015 at 1:07 PM, Nicolai Hess <nicolaihess(a)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-li…> >>> 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(a)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

Nov. 16, 2015

Re: [Pharo-dev] ubuntu ppa not up-to-date

by Torsten Bergmann

Thanks a lot! > Gesendet: Montag, 16. November 2015 um 19:46 Uhr > Von: "Markus Fritsche" <mfritsche(a)reauktion.de> > An: "Pharo Development List" <pharo-dev(a)lists.pharo.org> > Betreff: Re: [Pharo-dev] ubuntu ppa not up-to-date > > Done! > > Am 16.11.2015 um 18:35 schrieb Markus Fritsche: > > Hi Peter, hello list, > > > > I am going to update it today. > > > > Kind regards, > > Markus > > >

Nov. 16, 2015

Re: [Pharo-dev] ubuntu ppa not up-to-date

by Markus Fritsche

Done! Am 16.11.2015 um 18:35 schrieb Markus Fritsche: > Hi Peter, hello list, > > I am going to update it today. > > Kind regards, > Markus

Nov. 16, 2015

Re: [Pharo-dev] Help me to understand where I screwed up QAâ¦

by Yuriy Tymchuk

I have already installed the newest one, and it works. Thank you for helping me out! > On 16 Nov 2015, at 18:40, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > > > > On Mon, Nov 16, 2015 at 6:54 AM, Yuriy Tymchuk <yuriy.tymchuk(a)me.com <mailto:yuriy.tymchuk@me.com>> wrote: > Maybe my VM is rusty :) > > If you invoke it on the command line with the -version flag it'll tell you what version it is and when i was compiled. Would you mind checking? > > > We need to put pharo launcher on Appstore, so it will ask for updates automatically. > > Thanks. > Uko > > > > On 16 Nov 2015, at 15:48, Marcus Denker <marcus.denker(a)inria.fr <mailto:marcus.denker@inria.fr>> wrote: > > > > I can not reproduce it here (with a recent VM). > > > > Marcus > > > >> On 16 Nov 2015, at 11:40, Eliot Miranda <eliot.miranda(a)gmail.com <mailto:eliot.miranda@gmail.com>> wrote: > >> > >> Hi Yuriy, > >> > >> this looks like an old VM bug. Are you sure you're using the most up-to-date VM? > >> > >> _,,,^..^,,,_ (phone) > >> > >>> On Nov 16, 2015, at 6:02 AM, Yuriy Tymchuk <yuriy.tymchuk(a)me.com <mailto:yuriy.tymchuk@me.com>> wrote: > >>> > >>> Hi everyone, > >>> > >>> this is a weird issue that wasnât there when I was developing the feature. > >>> > >>> If inspector plugin is enabled in prefs and you inspect a method (e.g. Object>>#asString) you get âMessageNotUnderstood: SmallInteger>>notEmptyâ on â(critics := self critics) notEmptyâ. If you inspect critics temporary itâs a Set, if you restart in debugger and step over it works well, but for some reason initially notEmpty is sent to some int. Any idea what is the issue? > >>> > >>> Cheers, > >>> Uko > >> > > > > > > > > > > -- > _,,,^..^,,,_ > best, Eliot

Nov. 16, 2015

[pharo-project/pharo-core]

by GitHub

Branch: refs/tags/50447 Home: https://github.com/pharo-project/pharo-core

Nov. 16, 2015

[pharo-project/pharo-core] 2b7d80: 50447

by GitHub

Branch: refs/heads/5.0 Home: https://github.com/pharo-project/pharo-core Commit: 2b7d80148133c9cb10002dc1010e6dcab5e881c3 https://github.com/pharo-project/pharo-core/commit/2b7d80148133c9cb10002dc1… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2015-11-16 (Mon, 16 Nov 2015) Changed paths: M Kernel.package/Class.class/instance/copying/copy.st R Nautilus.package/AbstractNautilusUI.class/instance/accessing/showHierarchy_.st R Nautilus.package/AbstractNautilusUI.class/instance/private/resetPackageGroupsList.st M Nautilus.package/AbstractNautilusUI.class/instance/private/updateGroupView.st M Nautilus.package/AbstractNautilusUI.class/instance/private/updatePackageGroupAndClassList.st M Nautilus.package/AbstractNautilusUI.class/instance/private/updatePackageView.st M Nautilus.package/AbstractNautilusUI.class/instance/private/updatePackageViewAndMove.st M Nautilus.package/AbstractNautilusUI.class/instance/private/updatePackageViewContent.st A Nautilus.package/AbstractWidget.class/instance/accessing/hasFocus.st A Nautilus.package/AbstractWidget.class/instance/accessing/takeKeyboardFocus.st M Nautilus.package/MethodWidget.class/class/menu/elementsMenu_.st M Nautilus.package/PackageTreeNautilusUI.class/instance/accessing/showHierarchy_.st M Nautilus.package/PackageTreeNautilusUI.class/instance/private/basicShowHierarchy.st M Nautilus.package/PackageTreeNautilusUI.class/instance/private/clearPackageSelections.st M Nautilus.package/PackageWidget.class/definition.st M Nautilus.package/PackageWidget.class/instance/initialization/initialize.st R Nautilus.package/PackageWidget.class/instance/protocol/resetPackageGroupList.st M Reflectivity.package/Breakpoint.class/instance/api/always.st M Reflectivity.package/Breakpoint.class/instance/api/once.st M Reflectivity.package/Breakpoint.class/instance/api/when_.st A Reflectivity.package/Breakpoint.class/instance/links/breakLink.st A Reflectivity.package/Breakpoint.class/instance/links/breakLinkConditional.st A Reflectivity.package/Breakpoint.class/instance/links/breakLinkOneShot.st R Reflectivity.package/Breakpoint.class/instance/links/conditionalHaltLink.st R Reflectivity.package/Breakpoint.class/instance/links/haltLink.st R Reflectivity.package/Breakpoint.class/instance/links/haltLinkOneShot.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50446.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50447.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50446.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50447.st M ScriptLoader50.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st M Slot.package/extension/ClassDescription/instance/superclass_layout_.st M SmartSuggestions.package/SugsBreakpointSuggestion.class/instance/breakpoints/breakpointSelectionMenu.st M Traits.package/TClassDescription.class/instance/initialize-release/superclass_methodDictionary_format_.st Log Message: ----------- 50447 17025 unify naming: break, not halt https://pharo.fogbugz.com/f/cases/17025 17023 Do not update instanceVariables ivar https://pharo.fogbugz.com/f/cases/17023 17020 PackageWidget has un-used packagesListElements variable https://pharo.fogbugz.com/f/cases/17020 http://files.pharo.org/image/50/50447.zip

Nov. 16, 2015