WWI Epitaph

  • If any question why we died,
    Tell them, 'Because our fathers lied.'
    — Rudyard Kipling
Blog powered by Typepad
Member since 02/2005

« iDisemvowelU | Main | Stupid Documentation Tricks: Apple's "Using Subversion with Xcode 3 on Mac OS X Leopard" »



Jon Reid

Evan, your torture-testing idea alone is worth every penny of my subscription!

I haven't played with the iPhone SDK yet, but I'm puzzled about the autorelease pool. On a regular Mac, I thought it got cleaned out frequently, by the event loop. Not so on the iPhone?

The memory leak example and counter-example look strange. Doesn't dcsText release its text member when it is dealloc'd?

Evan Robinson

As I understand it, you're confusing autorelease and garbage collection. What an autorelease pool does is keep a pointer to whatever objects you put in it, thus guaranteeing that those objects stay around throughout the lifetime of the autorelease pool (until it is drained). The iPhone does not have garbage collection.

The problem with the memory leak example is that the [[NSString alloc] init...] pair allocates a block of memory with a retainCount of 1. But without a pointer to that block of memory, it can't be released (which reduces the retainCount by 1, deallocating the block when the retainCount reaches 0).

So, on a theoretical basis, I could do a release on dcsText.text when I'm done with it, or changing it. Which means that, actually, what I've shown isn't necessarily a memory leak: it could be lazily released. But it's not automatically released.

Jon Reid

OK, learning the new dot-notation for property access helps me understand. Assuming the 'text' property has been declared with the 'retain' property, then dcsText.text = foo calls an automatically generated setText: method, which does a retain. And hence the leak.

The comments to this entry are closed.