2

I have brought back a root object from being encoded with NSCoder and have no idea how to memory manage this returned object. I have surrounded it with an autorelease pool, but the object doesn't go out with the pool. Code Here, See line 289 Line and code may change with Git Hub commits, but ultimately you will see the answer in working code, fingers crossed.

Since:

What is a guaranteed way to fully cause a deallocation of my decoded object?

cxx6xxc
  • 171
  • 8
  • What object is staying around longer than you expect? You shouldn't worry about "causing deallocation" so long as you're following the usual memory management rules. – Jesse Rusak Jan 15 '13 at 01:14
  • This object has the potential for very large amount of data, I insist I must know for sure removal is at the least imminent. – cxx6xxc Jan 15 '13 at 08:40

2 Answers2

1

You're managing memory returned from NSKeyedArchiver.

You either need to explicitly retain it, and call release when you are done, or use it immediately--such as write to file.

I recommend re-familiarizing yourself with the Memory Management Rules for Objective-C

Manual Memory Management is a bit tricky at first, but once you get the hang of the rules, it makes situations like this very easy to work through.

Now, if you need to ensure that the memory is removed immediately, you will need to write your own binary serializer that will follow the alloc:init pattern so the caller explicitly owns the memory. That way when you call release on the object, it will be deallocated.

Alan
  • 45,915
  • 17
  • 113
  • 134
  • It lasts past my test function without a retain. Is not that considered a leak when I am not in control of atleast starting the dealloc process? Line 275: https://github.com/cxx6xxc/Node/blob/master/nodeInterface.m – cxx6xxc Jan 15 '13 at 08:31
  • No. It's not a leak. Internally when the memory is allocated, it is added to the AutoRelease pool, and when the pool is drained, it will be deallocated. IIRC you don't have control of when that AutoRelease pool is drained, as it's managed by the OS. If you want to verify, you can call release on the object manually, which will decrement the ref count, and should dealloc the memory (but will introduce a very bad bug when the AutoRelease pool empties--so don't leave it in!!). – Alan Jan 15 '13 at 18:02
  • It seems to act different than other foundation autorelased instances. For example, NSString has to retained if autoreleased right away. Whereas not retaining the NSCoder objects seems irrelevant, because they still reside in memory several times through the app event loop. For testing, I have sent 4 release messages which imply it has a retain count of 4. Later on, I do not get the typical over release segmentation on app shutdown, whereas if I release an autorelease NSString I would. So, I'm confused why NSCoder is doing this. It doesn't seem to act consistent. – cxx6xxc Jan 17 '13 at 22:28
0

NSCoder doesn't belong to that release pool.

Nico
  • 3,826
  • 1
  • 21
  • 31