[Vm-dev] Cog VM Crash on Windows

Nicolas Cellier nicolas.cellier.aka.nice at gmail.com
Sun Mar 10 16:55:42 UTC 2013


In other words, this would be a bug in ClassBuilder, but would strike
only COG VM, because a cogit unlinkSend is missing.
A traditional VM would properly clear the cache by selector (primitive 119).

Nicolas

2013/3/10 Nicolas Cellier <nicolas.cellier.aka.nice at gmail.com>:
> I'd like to understand this.
>
> MC mecahnism should invoke primitive 116 (primitiveFlushCacheByMethod,
> CompiledMethod>>flushCache) on OLD CompiledMethod when recompiled in
> newClass.
> This will invoke
>
> cogit unlinkSendsTo: self stackTop andFreeIf: false
>
> where stackTop is the old CM.
> But for some reason - ClassBuilder is relatively complex - the
> recompilation is invoked with an empty MethodDictionary, so this
> primitive is not invoked.
>
> primitive 119 (primitiveFlushCacheSelective, Symbol>>flushCache) is
> invoked then, but will apparently not cogit unlinkAnything.
>
> The super hammer primitive 89 (primitiveFlushCache,
> Behavior>>flushCache) would unlink thru flushMethodCache which:
>
> cogit unlinkAllSends
>
> But, primitive 89 is not invoked in MC createClass process.
>
> If I add Object flushCache at the end of ClassBuilder>>mutate:to:, I
> can download various versions of Compiler without trouble.
> Is my cache analysis correct and could it be the origin of the problem?
>
> Nicolas
>
> 2013/3/8 Nicolas Cellier <nicolas.cellier.aka.nice at gmail.com>:
>> 2013/3/8 Nicolas Cellier <nicolas.cellier.aka.nice at gmail.com>:
>>> To illustrate it, see the attached stack trace when I attempt to load
>>> an OrderedCollection(a MCVersion(Compiler-eem.252)) from an up to date
>>> trunk image:
>>>
>>
>> Grrr, sorry, I tried so many combinations...
>> This was not an up-to-date Squeak image, I at least reverted my last
>> version of Metacello in order to trigger this simple bad behaviour.
>> So the recipe would be to load first Monticello-fbs.532 then
>> Compiler-eem.252 from an up-to-date trunk image with a COG VM (no
>> crash this way back, beacuse we add slots) and attempt the same with
>> an Interpreter VM (no problem at all).
>>
>> Nicolas
>>
>>> No obsolete Parser/Compiler compiledMethod sender on the call stack,
>>> but an obsolete Parser compiledMethod disagreeing on cue position,
>>> sent AFTER the recompilation of Parser, which is not expected.
>>>
>>> No such Behavior with interpreter VM, for me it is clearly a COG VM
>>> bug, some cache is not properly flushed or something...
>>>
>>> Nicolas
>>>
>>> 2013/3/8 Nicolas Cellier <nicolas.cellier.aka.nice at gmail.com>:
>>>> 2013/3/8 Jeff Gonis <jeff.gonis at gmail.com>:
>>>>>
>>>>> On Fri, Mar 8, 2013 at 10:49 AM, Eliot Miranda <eliot.miranda at gmail.com> wrote:
>>>>>>
>>>>>> This is known.  It is a bug in the update. not the VM.  The update
>>>>>> causes the VM to read off the end of a Parser instance.  It would
>>>>>> crash the Interpreter VM too.
>>>>>>
>>>>>> best,
>>>>>> Eliot
>>>>>
>>>>
>>>> Hmm, looking at it again, I'm not convinced.
>>>> First, I tried several times from an Interpreter Vm and that never
>>>> triggered any bug.
>>>> Then I don't see how the update could fail.
>>>>
>>>> In MCClassDefinition>>createClass we use
>>>> class := (ClassBuilder new)
>>>>                         name: name
>>>>                         inEnvironment: superClass environment
>>>>                         subclassOf: superClass
>>>>                         type: type
>>>>                         instanceVariableNames: self instanceVariablesString
>>>>                         classVariableNames: self classVariablesString
>>>>                         poolDictionaries: self sharedPoolsString
>>>>                         category: category.
>>>>
>>>> This is a quite robust process, because it creates a newClass clone
>>>> first, compile all the methods from oldClass into newClass, and then
>>>> mutate allInstances of oldClass into instances of newClass.
>>>>
>>>> What can fail is having an obsolete CompiledMethod on stack with wrong
>>>> inst var slots.
>>>>
>>>> What I observed with COG VM is different.
>>>> I change Parser with above ClassBuilder snippet.
>>>> Then in previous version of createClass, this snippet fails in
>>>> (Compiler evaluate: ...) part :
>>>>
>>>>         composition := Compiler evaluate: (self traitComposition ifNil:['{}']).
>>>>         (composition isCollection and:[composition isEmpty and:[class
>>>> traitComposition isEmpty]]) ifFalse:[
>>>>                 class setTraitComposition: composition asTraitComposition.
>>>>         ].
>>>>
>>>> with an obsolete Parser method...
>>>> It's like COG VM is still using an old Parser methodDictionary, while
>>>> we just changed it...
>>>>
>>>> Nicolas
>>>>
>>>>> Ok thanks, I wasn't sure if this was the same bug and I figured it was
>>>>> safer to send in a report than not.  Didn't mean to spam the list.
>>>>>
>>>>> Thanks for your time,
>>>>> Jeff


More information about the Vm-dev mailing list