Always Test in Real - Not Just Crappy - User Device

Memory related defects can be hard to debug, therefore I usually force automatic system "out of memory" notifications. That makes sure I have no other choice, but to handle potential OOM issues from the start. Otherwise the app won't run. Clever, right?

And that's the problem. Potential OOM issues. Did you notice that "potential" keyword?

GDB: Program received signal: "EXC_BAD_ACCESS"

When your program crashes (not if, but when) with an error message...

GDB: Program received signal: "EXC_BAD_ACCESS"

...you know that there is most likely a memory leak somewhere. Your code just tried to access something, which was supposed to be there, which used to be there, which is going to be there, which should have been there - but right now is missing.

How to Make Instruments Show Your Own Code

Debugging memory leaks with Instruments. Great tool, but would be more useful, if I could see there references to my code.

Turned out it's a known iPhone OS 3.0 defect, almost two years old! No idea why it hasn't been fixed by Apple. Maybe old SDKs are not supported on purpose, which does make some business sense.

How to fix: Go to your Xcode project, select project info, go to Build tab and search Base SDK. Change your project Base SDK to 3.1. I had there 3.0, which seems to be a known defect.

• Build - Clean All Targets - select all - Clean
• Build - Build and Analyze
• Run - Run with Performance Tool - Leaks
• Stop
• Open popup item with application name - Launch Executable - Choose Executable
• Browse to your Build directory and select your application
• Record (the red Dot button)

It's not enough to start your application from Instruments, but you also have to choose the file. Stop and Record is not enough.