[Glass] error upgrading stone: become is not allowed

Johan Brichau via Glass glass at lists.gemtalksystems.com
Thu Apr 27 08:48:01 PDT 2017


A bit more info… I did a lookup of the oops mentioned in the call of become:

In the source 2.4 extent:
	The receiver object with oop 4489369089 does not exist
	The argument object with oop 148062465 is an instance of NPGsFileWrapper

In the destination 3.2 extent (following the failed bulk migrate after application load):
	The receiver object with oop 4489369089 is an object anArray( #'switch')
	The argument object with oop 148062465 is still that instance of NPGsFileWrapper

When I executed: SystemRepository findReferencePathToObject: (Object _objectForOop: 4489369089), I got:
a ArgumentError occurred (error 2027), A committed object was expected rather than object anArray( #'switch'), which is either special or uncommitted.

> On 27 Apr 2017, at 17:22, Johan Brichau <johan at yesplan.be> 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?
> Or do we need to move away from having instances of classes that are subclasses of GsFile before we attempt to upgrade?
> 
> thx
> Johan



More information about the Glass mailing list