[Vm-dev] Cog VM Crash on Windows

[Nicolas Cellier]

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