Re: Unarchiving issues
Thanks, everybody. Of course, you're all absolutely right, the buffer from decodeBytesForKey is temporary. I'd just assumed the bytes would be written to my malloced buffer, not realizing I needed to explicitly copy them. Problem solved. cheers, J. On 2010-08-02, at 10:56 AM, Graham Cox wrote: > > On 03/08/2010, at 3:46 AM, James Maxwell wrote: > >> continuations = (float*)[aDecoder >> decodeBytesForKey:@"continuations" returnedLength:&size]; > > > I expect the returned bytes are autoreleased. The docs don't state this > explicitly, but the similar method -decodeBytesWithReturnedLength: states "If > you need the bytes beyond the scope of the current autorelease pool, you must > copy them.". > > Try it and see if it solves the issue, sounds like a straightforward memory > bug. > > --Graham > James B Maxwell Composer/Doctoral Student School for the Contemporary Arts (SCA) School for Interactive Arts + Technology (SIAT) Simon Fraser University jbmaxw...@rubato-music.com jbmax...@sfu.ca ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Unarchiving issues
On Aug 2, 2010, at 12:46 PM, James Maxwell wrote: > // set the contents of the array > continuations = (float*)[aDecoder > decodeBytesForKey:@"continuations" returnedLength:&size]; >From the header file: - (const uint8_t *)decodeBytesForKey:(NSString *)key returnedLength:(NSUInteger *)lengthp; // returned bytes immutable, and they go away with the unarchiver, not the containing autorlease pool And from the documentation: Discussion The returned value is a pointer to a temporary buffer owned by the receiver. The buffer goes away with the unarchiver, not the containing autorelease pool. You must copy the bytes into your own buffer if you need the data to persist beyond the life of the receiver. So if your setContinuationSize: allocates memory, you should: const uint8_t *bytes = [aDecoder decodeBytesForKey:@"continuations" returnedLength:&size]; NSAssert(size == [self continuationsSize] * sizeof(float), @"Bad size of bytes returned from decoding"); memcpy(continuations, bytes, size); Glenn Andreas gandr...@gandreas.com The most merciful thing in the world ... is the inability of the human mind to correlate all its contents - HPL ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Unarchiving issues
On 03/08/2010, at 3:46 AM, James Maxwell wrote: > continuations = (float*)[aDecoder > decodeBytesForKey:@"continuations" returnedLength:&size]; I expect the returned bytes are autoreleased. The docs don't state this explicitly, but the similar method -decodeBytesWithReturnedLength: states "If you need the bytes beyond the scope of the current autorelease pool, you must copy them.". Try it and see if it solves the issue, sounds like a straightforward memory bug. --Graham ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Unarchiving issues
Okay, so here's the initWithCoder from the object that's giving me grief. The
variable "continuations" is a float* array, and appears to load fine from here,
but disappears once the root object is unarchived and set. I've since
discovered that, through a mistake I made at another place in the code, I've
been shielded from noticing that all of my encoded float* arrays appear to be
doing the same disappearing act. So, I assume I'm doing something really wrong
here:
- (void)encodeWithCoder:(NSCoder
*)aCoder
{
// the size for the saved vector
NSUInteger size = ([self continuationsSize] * sizeof(float));
// save the length variable
[aCoder encodeInt:[self continuationsSize] forKey:@"continuationsSize"];
// encode the float* bytes
[aCoder encodeBytes:(uint8_t*)continuations length:size
forKey:@"continuations"];
}
- (id) initWithCoder:(NSCoder *)aDecoder
{
if(self = [super init])
{
NSUInteger size;
// init a bunch of other stuff
// set the size of the array (the accessor does the malloc)
[self setContinuationsSize:[aDecoder
decodeIntForKey:@"continuationsSize"]];
// set the contents of the array
continuations = (float*)[aDecoder
decodeBytesForKey:@"continuations" returnedLength:&size];
}
return self;
}
Thanks in advance,
J.
On 2010-08-01, at 8:34 PM, Michael Ash wrote:
> On Sun, Aug 1, 2010 at 3:30 PM, James Maxwell
> wrote:
>> Hello All,
>>
>> I have a strange problem with NSKeyedArchiver/Unarchiver. I have a very
>> complex object graph that I want to be persistent, independently of my
>> document objects, so I'm archiving it into the user's application support
>> folder. The root object for the archive is a class called Network, which
>> basically stores very little, but does store the "Hierarchy" for the object
>> graph, which is basically just a 2D NSMutableArray (though it's a pretty big
>> one). When I unarchive my Network root object, and initWithCoder gets called
>> in the Network class, the Hierarchy seems fine -- I can iterate over the
>> objects, posting relevant data, and everything looks good. However, once the
>> Network is loaded into the application, iterating over the loaded Network
>> Hierarchy gives an exc_bad_access error. I'm using the same routine to post
>> the data, so nothing's changed there.
>> The data that's causing the problem is a float* array, saved using
>> encodeBytes:length:forKey, and decoded using
>> decodeBytesForKey:returnedLength:, which is how I've saved a number of
>> similar float* arrays in the Hierarchy.
>> What I don't understand is how the Hierarchy can be fine at the end of the
>> Network's initWithCoder method, but then get banjaxed somehow after that.
>
> Post your code. It's *much* easier to debug code than a loose
> description of code.
>
> Mike
> ___
>
> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
>
> 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:
> http://lists.apple.com/mailman/options/cocoa-dev/jbmaxwell%40rubato-music.com
>
> This email sent to jbmaxw...@rubato-music.com
James B Maxwell
Composer/Doctoral Student
School for the Contemporary Arts (SCA)
School for Interactive Arts + Technology (SIAT)
Simon Fraser University
jbmaxw...@rubato-music.com
jbmax...@sfu.ca
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Re: Unarchiving issues
On Sun, Aug 1, 2010 at 3:30 PM, James Maxwell wrote: > Hello All, > > I have a strange problem with NSKeyedArchiver/Unarchiver. I have a very > complex object graph that I want to be persistent, independently of my > document objects, so I'm archiving it into the user's application support > folder. The root object for the archive is a class called Network, which > basically stores very little, but does store the "Hierarchy" for the object > graph, which is basically just a 2D NSMutableArray (though it's a pretty big > one). When I unarchive my Network root object, and initWithCoder gets called > in the Network class, the Hierarchy seems fine -- I can iterate over the > objects, posting relevant data, and everything looks good. However, once the > Network is loaded into the application, iterating over the loaded Network > Hierarchy gives an exc_bad_access error. I'm using the same routine to post > the data, so nothing's changed there. > The data that's causing the problem is a float* array, saved using > encodeBytes:length:forKey, and decoded using > decodeBytesForKey:returnedLength:, which is how I've saved a number of > similar float* arrays in the Hierarchy. > What I don't understand is how the Hierarchy can be fine at the end of the > Network's initWithCoder method, but then get banjaxed somehow after that. Post your code. It's *much* easier to debug code than a loose description of code. Mike ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Unarchiving issues
On Aug 1, 2010, at 13:31, James Maxwell wrote: > heh... yeah, that's true. But the thing is I haven't done anything different > with this particular float* array. It's the same type of archiving I've used > at many points in the app. > But I hadn't thought to look for weak references could this be as simple > as making sure to type cast objects when adding them to mutable arrays? Anything in an array is strongly referenced, so you don't have to worry about it. The problem is more likely the array itself, or the root unarchived object (Network, did you say?) ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Unarchiving issues
heh... yeah, that's true. But the thing is I haven't done anything different with this particular float* array. It's the same type of archiving I've used at many points in the app. But I hadn't thought to look for weak references could this be as simple as making sure to type cast objects when adding them to mutable arrays? J. On 2010-08-01, at 1:19 PM, Quincey Morris wrote: > On Aug 1, 2010, at 12:30, James Maxwell wrote: > >> What I don't understand is how the Hierarchy can be fine at the end of the >> Network's initWithCoder method, but then get banjaxed somehow after that. > > Sure you do. Things disappear suddenly when not retained or strongly > referenced. You're describing one of the classic manifestations of a memory > management error. > > > ___ > > Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) > > 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: > http://lists.apple.com/mailman/options/cocoa-dev/jbmaxwell%40rubato-music.com > > This email sent to jbmaxw...@rubato-music.com James B Maxwell Composer/Doctoral Student School for the Contemporary Arts (SCA) School for Interactive Arts + Technology (SIAT) Simon Fraser University jbmaxw...@rubato-music.com jbmax...@sfu.ca ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Unarchiving issues
On Aug 1, 2010, at 12:30, James Maxwell wrote: > What I don't understand is how the Hierarchy can be fine at the end of the > Network's initWithCoder method, but then get banjaxed somehow after that. Sure you do. Things disappear suddenly when not retained or strongly referenced. You're describing one of the classic manifestations of a memory management error. ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Unarchiving issues
Hello All, I have a strange problem with NSKeyedArchiver/Unarchiver. I have a very complex object graph that I want to be persistent, independently of my document objects, so I'm archiving it into the user's application support folder. The root object for the archive is a class called Network, which basically stores very little, but does store the "Hierarchy" for the object graph, which is basically just a 2D NSMutableArray (though it's a pretty big one). When I unarchive my Network root object, and initWithCoder gets called in the Network class, the Hierarchy seems fine -- I can iterate over the objects, posting relevant data, and everything looks good. However, once the Network is loaded into the application, iterating over the loaded Network Hierarchy gives an exc_bad_access error. I'm using the same routine to post the data, so nothing's changed there. The data that's causing the problem is a float* array, saved using encodeBytes:length:forKey, and decoded using decodeBytesForKey:returnedLength:, which is how I've saved a number of similar float* arrays in the Hierarchy. What I don't understand is how the Hierarchy can be fine at the end of the Network's initWithCoder method, but then get banjaxed somehow after that. Any thoughts greatly appreciated. J. James B Maxwell Composer/Doctoral Student School for the Contemporary Arts (SCA) School for Interactive Arts + Technology (SIAT) Simon Fraser University jbmaxw...@rubato-music.com jbmax...@sfu.ca ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
