bugGNUstep - Bugs: bug #16218, Problem with NSKeyedArchiver

Group
 
 

bug #16218: Problem with NSKeyedArchiver

Submitter:  Michael Johnston <mjohnston>
Submitted:  Wed 29 Mar 2006 05:38:54 PM UTC
   
 
Category:  Base/Foundation Severity:  3 - Normal
Item Group:  Bug Status:  Ready For Test
Privacy:  Public Assigned to:  None
Open/Closed:  Closed
* Mandatory Fields

Add a New Comment Rich Markup
   

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>
Group 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>
Group 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>
Group 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>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

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
  • -email is unavailable- added by FredKiefer (Updated the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.

     

    Follow 11 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2007-10-14 FredKiefer Open/ClosedIn Test Closed
    2006-04-10 FredKiefer StatusNeed Info Ready For Test
        Open/ClosedOpen In Test
    2006-04-05 mjohnston Attached File- Added codedObjects.tar, #9718
    2006-03-31 FredKiefer StatusInvalid Need Info
        Open/ClosedDeclined Open
    2006-03-30 mjohnston Attached File- Added Logs.tar, #3529
    2006-03-29 FredKiefer CategoryLibraries Base/Foundation
        StatusNone Invalid
        Open/ClosedOpen Declined
    2006-03-29 mjohnston Attached File- Added Archives.tar, #3526

    Back to the top

    Powered by Savane 3.13-f8d8.
    Corresponding source code