I was seeing a very strange description for an NSMutableArray object in XCode.  Instead of viewing the array’s count, as I expected, I was seeing some garbled message that said {(int)[$VAR count]} objects:

A quick google search pointed me to a conversation about this on stackoverflow. The key point in that link is this, made by Quinn Taylor:

it’s possible that the object has been reclaimed (either by -dealloc or GC) so check to make sure it’s retained if needed.

AH-HA!!  I am screwing up my memory management again!

For some context, I went back to the Objective-C bootcamp chapter of the iPhone Developer’s Cookbook, and sure enough, Erica Sadun talks about this on page 112:

Retaining objects set to autorelease allows them to persist beyond a single method.

The problem? My array was created by calling [NSMutableArray array], which returns an autoreleased NSMutableArray object.  Thus, it was disappearing once I left the method where I created it.

Changing my code from:


solved my problem.  Huzzah!

6 Responses to “Basic Memory Management: EFF-ing up my arrays”  

  1. 1 guy smiley

    “Retaining objects set to autorelease allows them to persist beyond a single method.”

    this is not what retain means. it is critically important to understand that. avoid anyone else’s (erica sadun’s) reformulation of the cocoa memory management rules. just read apple’s cocoa memory docs. they’re astonishingly simple and straightforward. time and time again, people reword the guidelines in their own voice and make statements that contain or otherwise introduce subtle errors in the rules or how you should think about them.

    “[NSMutableArray array], which returns an autoreleased NSMutableArray ”

    this is a prime example of what i mean above. the documentation of nsarray/nsmutable does not state that the object you receive is autoreleased. in fact, the documentation explicitly avoids saying this. maybe you get an autoreleased object. maybe you don’t. it isn’t your concern. all you should care about is that /you don’t own it/ and may need to retain it, depending on the situation.

  2. 2 Richard L. Burton III

    Memory management in Objective-C has always been something I’ve disliked. Take the following quote from Apple:

    “You take ownership of an object if you create it using a method whose name begins with “alloc” or “new” or contains “copy” (for example, alloc, newObject, or mutableCopy), or if you send it a retain message. You are responsible for relinquishing ownership of objects you own using release or autorelease. Any other time you receive an object, you must not release it.”

    There’s a serious lack of thought when a rule is defined like this, not to mention that they actually make state the following afterwards “The following rules derive from the fundamental rule, or cope with edge cases”

    In the meanwhile, Google has made a good choice in their implementation for the Android platform. No only does performance excel, but you don’t need to worry yourself about such mornic rules. ;)

    Now here’s a question, do you really enjoy the error messages you receive during development? :)

    On that note, check out http://clang-analyzer.llvm.org/ it’ll help you identify bugs quicker.


    Richard L. Burton III

  3. 3 am

    Thank you so much for taking the time to comment and clarify this for me. I have printed out the memory management docs and have been reading slowly through them. I will post a corrected version of this blog soon. Again, thanks for your input!

  4. 4 am


    The errors are definitely frustrating, especially EXEC_BAD_ACCESS. Though i am usually able to debug them fairly quickly without too much hair-pulling :)

    Reading through the docs has definitely been helping me, and I actually don’t find it that unintuitive. But it’s certainly a slow process learning, as there is a not of material i need to absorb!

    Will you be at WWDC?

    What is your favorite thing about Android?

  5. 5 Thanks!

    Thank you! I was stuck for so long trying to understand why I was getting a memory error and this solved it! Thanks!

  6. 6 Austin

    Thanks a bunch for this, it got me back on track.


Leave a Reply