Hi,
I seem to have some sort of corruption in one of my Magma databases.
I'm running a Seaside application with Magma 0.41gamma1 and MagmaSeasideHelper.
I have 2 test images and 2 databases. Both images can access one of the databases with no problems. Trying to access the other database from either image results in a error. So I assume that there is something wrong with the "bad" database and not a problem with my images.
The error occurs during initial startup, beginning with:
^(WAMagmaSoloAuto forApp: 'CCS') rootAt: CCSServerRoot
The error is: STBUser cannot have variable sized instances
Looking through the call stack, things seem to go wrong in MaFixedObjectBuffer>>createObjectUsing:. Here, indexedSize is 2, which causes "skeleton" to be "class basicNew: indexedSize" instead of "class basicNew".
The root cause of this appears to be that the MagmaClassIdManager's class definitions for the STBUser. Version numbers are incorrect, or out of order in some way.
(results from exploring a MagmaClassIdManager, STBUser classId is 126)
| def | 1 to: 5 do: [:index | def := self definitionForClassId: 126 version: index. Transcript show: ('Index: ', (index printString), ' Version: ', (def version printString), ' ivar count: ', (def namedInstSize printString)); cr ]
Index: 1 Version: 4 ivar count: 5 Index: 2 Version: 5 ivar count: 6 Index: 3 Version: 2 ivar count: 9 Index: 4 Version: 1 ivar count: 10 Index: 5 Version: 3 ivar count: 11
When I look at other class definitions, the index and version numbers match. So something seems wrong.
The instance variable counts look right, but the version numbers appear to be wrong. Also, the inImageSerializer believes that we are on version 3:
def := (MaObjectSerializer allInstances first classIdManager inImageDefinition: STBUser). def version -> 3 def namedInstSize -> 11 (which is the correct number)
While in the debugger, I re-ordered the definitions for STBUser by the version number and resumed. This actually resulted in the application starting up successfully, and all my data for my newly added users was present.
However I'm sure if the in-image definition was thought to be 4 or 5 then my ivar count would have been off and the STBUsers would have failed to load again.
So it appears that there are too many versions in Magmas' class definition collection for my class, and those versions are out of order.
Somehow I always manage to make interesting errors!
Also: after re-arranging those class definitions and closing the Magma session, closing my image without saving, and restarting the image, my application opened with no problems. So I guess my changes to the Magma class definitions were persisted. However, that does leave me with version 4 and 5 definitions; while the in-image version of STBUser is 3. I'm sure I could go in and remove those definitions, and close the session and everything will be OK.
So my questions are:
Any idea how this could have possibly happened?
How can I fix it permanently, preferably through a code patch and not manual "live" tinkering? (The bad database I am testing with is a copy of a currently deployed system, which is currently working fine right now, but I'm sure it will break if I ever close and restart its image)
Is there any way to make sure it does not happen again?
Thanks,
Jerry Bell