bugGNUstep - Bugs: bug #16218, Problem with NSKeyedArchiver

 
 

You are not allowed to post comments on this tracker with your current authentication level.

bug #16218: Problem with NSKeyedArchiver

Submitted by:  Michael Johnston <mjohnston>
Submitted on:  Wed 29 Mar 2006 05:38:54 PM UTC  
 
Category: Base/FoundationSeverity: 3 - Normal
Item Group: BugStatus: Ready For Test
Privacy: PublicAssigned to: None
Open/Closed: Closed

(Jump to the original submission Jump to the original submission)

Mon 10 Apr 2006 12:04:34 AM UTC, comment #6:

It turns out that there really was a problem, but not with the decode, it was in the encoding of long NSData objects. And the worst bit here is that there already was a patch for this, but I did forget to apply one line from that patch by Derek Zhou. This should be fixed now.

I will later look into the problem, why the binary output i smuch slower. For the file you did send I was not able to reproduce a substantial performance difference.

Fred Kiefer <FredKiefer>
Project Member
Wed 05 Apr 2006 03:43:45 PM UTC, comment #5:

Unarchiving the binary coded form of the attached object raises the following exception when initForReadingWithData: is called -

NSRangeException, reason: in subdataWithRange:, range { 308, 45144 } extends beyond size (23225)

Michael Johnston <mjohnston>
Fri 31 Mar 2006 05:50:50 PM UTC, comment #4:

I opened up this bug report again.

Could you please attach examples of files where the keyed coding goes wrong. It would help if you provide an XML file with the corresponding binary format. Then I could try to understand the problem. It surely is just one special case which is not handled correctly, either in the encoding or in the decoding.

Fred Kiefer <FredKiefer>
Project Member
Thu 30 Mar 2006 01:56:45 PM UTC, comment #3:

I've been investigating this further I'm pretty sure there's something wrong with the new binary encoding. After changing all archiving operations to explicitly use NSPropertyListXMLFormat_v1_0 and reinstalling gnustep-startup-0.15 everything is uncoded correctly and the app behaves the same as under 0.14. Changing any of the archiving operations to use NSPropertyListBinaryForamt_v1_0
makes the resulting archive unreadable (except in the one case I attached in the original submission).

I also noticed performance issues with the binary format encoding. I've attached two logs (binaryFormat.log and xmlFormat.log) that show this by simply bracketing an encodeObject:forKey message with NSLogs. The object being encoded is an NSDictionary. Each object it contains is another dictionary with 8 NSNumbers. By comparing the logs you can see that the xml encoding is much faster (106secs to 0.5secs for 500 entries!) and linearly dependant on the number of objects while the binary encoding seems to follow some power dependancy.

btw Is there any way to set the encoding format globally through a default or programmatically so you can use archiveRootObject:toFile with a format other than the default?

Thanks

Michael

Michael Johnston <mjohnston>
Thu 30 Mar 2006 07:47:51 AM UTC, comment #2:

My original thought was that it was a binary file and the default encoding had changed but I could find no mention of any change in the docs. However I came to think it was a bug because most of the objects in my program when coded using the new format cannot be uncoded by the same library - the archive I attached was the exception.

The error returned when trying to decode many objects is of the type

(nil) in subdataWithRange:, range { 393926, 32877 } extends beyond size (424495)

or also

Unknown table size.

I wasnt very clear in the original submission but this is what I was referring to when I wrote "more complicated objects ... cant be unarchived at all". It could be due to a bug in my code somewhere but if so I don't understand how archiving/unarchiving would work in one format but not another.

Michael Johnston <mjohnston>
Wed 29 Mar 2006 06:21:21 PM UTC, comment #1:

Your problem is avtually not that GNUstep base has a bug, but that it is now closer to Cocoa. The default output format for the class NSKeyedArchiver is NSPropertyListBinaryFormat_v1_0 and what you are getting is not garbled output, but pretty valid binary encode stuff (At least I hope so, having writen that code).
Now if you want to get the old format back the only thing you need to do is tell the keyed archvier in which format you want the output:
[coder setOutputFormat: NSPropertyListXMLFormat_v1_0]

But what is wrong with a binary format, as long as you don't want to edit it manually?

Fred Kiefer <FredKiefer>
Project Member
Wed 29 Mar 2006 05:38:54 PM UTC, original submission:

On updating to gnustep-startup-0.15 from 0.14 NSKeyedArchiver started producing garbled output. I deleted all the new core library versions and reinstalled 0.14 and everything was back to normal.
I've attached the original plist that my app reads in and the archives produced using both gnustep-startup-0.14 and gnustep-startup-0.15. The plist isn't directly archived but is encoded as part of a light weight object. Strangely both startup versions can decode the archive produced by the 0.15 libraries. However more complicated objects, containing binary data for example, cant be unarchived at all.

I'm using Fedora Core 2 x86 with gcc 3.3 and I've replicated the same behaviour with Fedora Core 4 on an athlon laptop with gcc4.1.

Michael Johnston <mjohnston>

 

Attached Files
file #9718:  codedObjects.tar added by mjohnston (60KiB - application/x-tar)
file #1473:  Logs.tar added by mjohnston (10KiB - application/x-tar - Logs comparing binary v xml encoding times.)
file #1492:  Archives.tar added by mjohnston (30KiB - application/x-tar - Tar of the original plist and the two archives)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -unavailable- added by FredKiefer (Updated the item)
  •  

    Do you think this task is very important?
    If so, you can click here to add your encouragement to it.
    This task has 0 encouragements so far.

    Only logged-in users can vote.

     

    Please enter the title of George Orwell's famous dystopian book (it's a date):

     

     

    Follow 11 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Sun 14 Oct 2007 07:50:49 PM UTCFredKieferOpen/ClosedIn Test=>Closed
    Mon 10 Apr 2006 12:04:34 AM UTCFredKieferStatusNeed Info=>Ready For Test
      Open/ClosedOpen=>In Test
    Wed 05 Apr 2006 03:43:46 PM UTCmjohnstonAttached File-=>Added codedObjects.tar, #9718
    Fri 31 Mar 2006 05:50:50 PM UTCFredKieferStatusInvalid=>Need Info
      Open/ClosedDeclined=>Open
    Thu 30 Mar 2006 01:56:45 PM UTCmjohnstonAttached File-=>Added Logs.tar, #3529
    Wed 29 Mar 2006 06:21:21 PM UTCFredKieferCategoryLibraries=>Base/Foundation
      StatusNone=>Invalid
      Open/ClosedOpen=>Declined
    Wed 29 Mar 2006 05:38:54 PM UTCmjohnstonAttached File-=>Added Archives.tar, #3526

    Back to the top


    Powered by Savane 3.1-cleanup1