[Glass] error upgrading stone: become is not allowed

Dale Henrichs via Glass glass at lists.gemtalksystems.com
Thu Apr 27 10:57:15 PDT 2017



On 04/27/2017 08:22 AM, Johan Brichau via Glass wrote:
> Hi,
>
> In the conversion of a Gemstone 2.4.4.1 stone to Gemstone 3.2, I hit an error in the final step when loading our application code
>
> a ImproperOperation occurred (error 2426), become is not allowed on aNPGsFileWrapper, 'One object is a GsFile or RubySocket while the other is neither'
> Error Category: 231169 [GemStone] Number: 2426  Arg Count: 2 Context : 1906733569 exception : 4489410561
>
> We indeed have a subclass of GsFile, called NPGsFileWrapper
> Migrating the instances on application load seems to wrong, though both the old and new class are ‘NPGsFileWrapper’ (see stack context of the invocation of become: below)
>
> 5 NPGsFileWrapper (Object) >> become:           @4 line 112   [methId 59070977]
>      receiver [4489369089 sz:6 cls: 4487621633 NPGsFileWrapper] aNPGsFileWrapper
>      anObject [148062465 sz:4 cls: 6802930945 NPGsFileWrapper] aNPGsFileWrapper
>      self [4489369089 sz:6 cls: 4487621633 NPGsFileWrapper] aNPGsFileWrapper
>      prot [10 sz:0 cls: 74241 SmallInteger] 1 == 0x1
>
> Any way to circumvent this issue in the upgrade?
I guess to start with, I'd like to see more of the stack ... for some 
reason you are apparently getting a new class version of 
NPGsFileWrapper... there is a fair amount of logic in McClassDefinition 
(MCClassDefinition>>hasSimpleModsRelativeTo:) and the class creation 
code 
(Class>>_equivalentSubclass:superCls:name:newOpts:newFormat:newInstVars:newClassInstVars:newPools:newClassVars:inDict:constraints:isKernel:)that 
attempts to avoid creating new versions of a class unless "absolutely 
necessary."

So the first thing to explore is why you are migrating the class when no 
class versions should have been created --- assuming that the shape of 
the class NPGsFileWrapper hasn't changed ...

I am also curious what steps you've done to do the upgrade prior to 
loading. Ideally you would be doing something very similar to what is 
done by the GsDevKit_home upgradeStone script[1] ...

Dale

[1] https://github.com/GsDevKit/GsDevKit_home/blob/master/bin/upgradeStone
> Or do we need to move away from having instances of classes that are subclasses of GsFile before we attempt to upgrade?
>
> thx
> Johan
> _______________________________________________
> Glass mailing list
> Glass at lists.gemtalksystems.com
> http://lists.gemtalksystems.com/mailman/listinfo/glass



More information about the Glass mailing list