[Vm-dev] Cog VM Crash on Windows

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


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