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
