Re: gorm loading problem / binary compatibility

[Fred Kiefer]

On 17.03.2013 16:36, Riccardo Mottola wrote:
> Hi,
>
> I have a problem with my application (closed source, but I can provide
> gorm files and/or some sort of "demo" that starts but does nothing). I
> worked on it on NetBSD/x86. To my knowledge the machine runs SVN. That
> is, barren of some subtle update bugs.
>
> I edited gorm files there which do not load on linux/x86.
>
> The error is similar to one of the binary compatibilities found before
> release, but I wonder why it is happening now.
>
> #0  -[NSException raise] (self=0x820b2a4,
>      _cmd=0xb7a9c9a0 <_OBJC_SELECTOR_TABLE+192>) at NSException.m:955
> #1  0xb77cf689 in +[NSException raise:format:arguments:] (
>      self=0xb7a9ca40 <_OBJC_Class_NSException>,
>      _cmd=0xb7a9c988 <_OBJC_SELECTOR_TABLE+168>,
>      name=0xb7a9cb14 <_OBJC_INSTANCE_3>, format=0xb7ad64a4
> <_OBJC_INSTANCE_2>,
>      argList=0xbfffdbb0 "\021> ·\032> ·") at NSException.m:849
> #2  0xb77d0605 in +[NSException raise:format:] (
>      self=0xb7a9ca40 <_OBJC_Class_NSException>,
>      address@hidden <_OBJC_SELECTOR_TABLE>,
>      name=0xb7a9cb14 <_OBJC_INSTANCE_3>,
>      address@hidden <_OBJC_INSTANCE_2>) at
> NSException.m:835
> #3  0xb78a8d8f in typeCheck (t2=26 '\032', t1=<optimized out>)
>      at NSUnarchiver.m:248
> #4  typeCheck (t2=26 '\032', t1=<optimized out>) at NSUnarchiver.m:645
> #5  -[NSUnarchiver decodeValueOfObjCType:at:] (self=0x824f6f4,
>      _cmd=0xb7f010d0 <_OBJC_SELECTOR_TABLE+208>, type=0xb7e16800 "I",
>      address=0x81cc17c) at NSUnarchiver.m:1022
> #6  0xb7cc8ea0 in -[NSParagraphStyle initWithCoder:] (self=0x81cc13c,
>      _cmd=0xb7ad6388 <_OBJC_SELECTOR_TABLE+232>, aCoder=0x824f6f4)
>      at NSParagraphStyle.m:473
> #7  0xb78a9335 in -[NSUnarchiver decodeValueOfObjCType:at:]
> (self=0x824f6f4,
>      _cmd=0xb7a8c098 <_OBJC_SELECTOR_TABLE+88>, type=0xb7a0f369 "@",
>
>
> My code says at line NSParagraphStyle.m:473 NSTextAlignment
>
> Could it be that it should read NSInteger, similar to the fix I commited
> on 21-2 for NSLineBreakMode?
>
> I tried that locally, but the gorm will still fail to load, with an
> exception at line 499, but perhaps ,y gorm file is "Broken" and needs to
> be salvaged somehow? Perhaps by reading and reasaving it with a special
> gui version?

Thank you for pointing out this issue. It looks like different compilers 
treat enumerators differently. Some seem to turn them into unsigned int, 
while others use int. To prevent this sort of problems I went through 
the whole gui encoding code and replaced enumerator types with the basic 
types that we used before. The should solve the problem for the future.
For your specific gorm file it would be best to recreate it from scratch 
or from an older backup. If this is not possible you could try to apply 
only half the change I made for NSParagraphStyle, the encoding bit and 
leave the decoding as it was. That way you are able to load the file in 
the incorrect format and store it in the corrected one. But don't forget 
to switch to the full change after that, or you wont be able to load the 
file again.

This also means that we need to do another gui release very soon, to 
prevent others from creating incorrect gorm files. (Although I don't 
expect to many people will store paragraph styles or events in gorm 
files) And that we need a lot more testing code for gui. If we had code 
that tries to load pre-created archives for every class that supports 
encoding, we would have noticed earlier.

Fred