Common iOS memory mistakes developers commit

Leave a comment

Some of the common mistakes an iOS developer does are provided below:

1. Missing dealloc method as part of  each Class

2. Missing [super dealloc] methods call in dealloc method.

3. Leaving NSLog statements in production ready code. Too much NSLog can consume lot of memory and your app will throw memory warning very soon.

4. Not being aware of the power of iOS debugger commands to nail the crashes. Environment variables NSZombieEnabled, NSDebugEnabled, MallocStackLogging can help you a lot in finding the reasons behind crashes.

5. When using the above commands, forgetting to disabled in the production code.

6. Not leveraging the power of accessors. To leverage their power read this document

7. Not setting pointers to nil after releasing. Even though this is not necessary,  doing this is will help us in avoiding any inadvertant usage of this object variable, unless it is reassigned with any other object.

8. Trying to use retainCount of objects created.  Since there is no  1 to 1 correspondence between the retain count and calls to  retain/release, it is better we refrain from sing this.  This link might be use ful .

This list will be a living list and I will keep updating it.

Memory Leaks named “open_handle_to_dylib_path”, RegisterEmbeddedAudioCodecs() and CPAThreadStart()

Leave a comment

Removing memory leaks in the  App  we develop would be an interesting act .(at least for me). And some times those leaks that have no rationale behind their occurrence can be a nightmare. And I went through this nightmare for over one week. I was gifted by the Instruments tool the following leaks in my app.

  • open_handle_to_dylib_path – Responsible library was CoreGraphics.
  • RegisterEmbeddedAudioCodecs() – AudioToolbox- (This occurred twice.)

For me the Instruments directed me to the line

int retVal = UIApplicationMain(argc, argv, nil, nil);

in the main.m file for first leak. I know there was no rationale behind this problem, but was unsure how I am going to prove it.

And the second problem also was of the same shade pointing me to the line

[audioPlayer play];

in my code.

All these time I was testing my app in iPhone Simulator and I got a way to prove these leaks were untrue.

So I tested my app in the iPhone and got cleared of these leaks. And I was very happy until, I saw another leak from the AudioToolbox library named “CPAThreadStart()”. I am on my way to fix it. But  a thread running in cocos2d gave me little bit of relief  that  the leak is present in AudioToolbox. So hoping that the leak is within AudioToolbox I am closing this post.