On 3 Mar 2014, at 7:36 am, [email protected] wrote: > If facing this I would: > > 1. In unarchiver:didDecodeObject: return a proxy object for inclusion in the > archive. Doing this in a class wise fashion might help pinpoint a problematic > class or instance. > > 2. in unarchiver:didDecodeObject: - if possible write a validation/internal > consistency method for the decoded objects (may be infeasible if the class > fauna is large but 1. may have provided some pointers).
Hi Jonathan, thanks for taking an interest. The delegate is where I'm trying to make sense of what I'm actually decoding, as suggested. Unfortunately, the delegate only has a 'did decode' method and not a 'will decode' method, so the ordering of the objects presented to the delegate is the reverse of the objects inited from the archive. This makes careful substitution quite difficult, because the top level objects are shown to the delegate last, long after the lower level objects they (ultimately) contain, and could be responsible for the problem, have been and gone. In my case it's the top level objects that are not being returned in the requested array, so if there was a 'will decode' method, a strategy could be to substitute those, then the next level of the hierarchy, and so on until the top level fails. Unfortunately with the reversing of the objects, this is much harder - I need to perform the substitutions from the bottom up rather than the top down, and doing that in a way that allows the object graph to still make any sort of sense is pretty difficult. The problem case has 694 objects in the archive. Since I suspect some sort of memory overflow to be causing the problem, I did attempt to use the usual tools for this - guard malloc, scribbling, etc, but nothing showed up. Once again the opaque nature of a framework class makes tracking down a bug extremely difficult - if the dearchiver were my own code it would probably become trivial. Are there any other tools I could use to detect memory corruption? --Graham _______________________________________________ Cocoa-dev mailing list ([email protected]) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [email protected]
