On 3 Mar 2014, at 5:09 pm, Graham Cox <[email protected]> wrote:
> 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? OK, I've identified the problem - and it's not memory corruption. It does throw up a new question though. In one of my class's -initWithCoder: method, I do some sanity checking on a number of values. If some of these values are zero, it indicates an unviable object, in that far, far down the track, these zero values are used in a calculation that leads to a NaN value being passed to Core Graphics. (div by zero). So, if I detect these zeros in -initWithCoder, I autorelease self, set self to nil and return nil. This is in accordance with the usual rules for -init. It appears as though doing this in -initWithCoder : may not be legitimate. This is only one object among hundreds, and not dearchiving it should not affect other objects in the archive. However, it does, in that returning nil here prevents objects which are peers of this one from being added to the array that should be returned - that's why the array is returned empty. It's as if the dearchiving code is using -arrayWithObjects:, but because the first item in the list is nil, the rest are skipped, even though they have been decoded fine. If I return a substitute object instead, everything else dearchives correctly. However, the substitute object is really undesirable - I'd rather it were simply removed. I can probably do that by some roundabout means, but the more general question here is whether returning nil from -initWithCoder: should be legitimate or not. After all, it's an init method, and it should follow the rules for all other init methods, shouldn't it? If it should, then NSKeyedUnarchiver must be considered to have a bug. If this isn't legitimate, then where is it documented? --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]
