Corrupt database?

Chris Muller asqueaker at gmail.com
Thu May 7 17:50:30 UTC 2009


Is STBUser a kind of Set?

On Thu, May 7, 2009 at 12:32 PM, Jerry Bell <jdbell at oxfordmetamedia.com> wrote:
> 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
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> _______________________________________________
> Magma mailing list
> Magma at lists.squeakfoundation.org
> http://lists.squeakfoundation.org/mailman/listinfo/magma
>


More information about the Magma mailing list