You may not impose any further restrictions on the exercise of the rights granted or affirmed under this License. For example, you may not impose a license fee, royalty, or other charge for exercise of rights granted under this License.

1. The pointer used to point to memory that was ok, but its chunk was deallocated.
2. The pointer is corrupt.

1. Run Build and Analyze. Make sure you fix or understand every single error it flags. I personally have 0 Build and Analyze errors in every project I have and I go out of my way to keep it that way. If I ever get a false positive, I figure out how to make Build and Analyze understand what is going on, so that it doesn’t flag it.
2. Run scan-build with all checks on. This isn’t built in, so if you’re in a hurry, skip this for now. scan-build is the project that Build and Analyze is based on. It can be run with much more thorough settings.
3. Set up Xcode so that it never deallocates. Instead, it turns objects into Zombies that complain if they are used. See Tip #1 on this post for instructions.

1. The pointer could have never been initialized.
2. The pointer could have been accidentally written over because you overstepped the bounds of an array
3. The pointer could be part of an object that was casted incorrectly, and then written to
4. Any of the above could have corrupted a different pointer that now points at or near this pointer, and using that one corrupts this one (and so on)

1. Enable Guard Malloc (Tip #2) - this makes the datastructure that represents the allocations much more sensitive to corruption. You need to use the enhanced features of the debugger to get anything out of it (explained in the tip).
2. The line of code that triggers the crash is a clue to what pointer is corrupt. If you move it around it might be able to help you narrow down the point of corruption.
3. If all else fails and you are desperate, try Valgrind.

1. Corrupting a pointer doesn’t immediately trigger EXC_BAD_ACCESS. Neither does using a corrupted pointer unless it’s specifically now pointing to memory that isn’t mapped to your application.
2. Deallocating an object doesn’t immediately release the memory to the operating system -- only when the chunk is unused, can it be returned.
3. The line of code that is triggering the EXC_BAD_ACCESS might not be the problem. It can be a good clue, but don’t assume the problem is this code.

1. Run Build and Analyze: This kind of Build is very good at finding retain/release bugs. Take a good look at everything it flags.
2. Even better, run scan-build. I did a test recently, and found that some common errors are off by default in Build and Analyze that can be turned on in scan-build.
3. Choose Run > Enable Guard Malloc in the menu, and then re-run your application. This finds a whole class of buffer overrun issues. If this detects it, you’ll see a better error in the console. Read this to see how to use Guard Malloc once it’s enabled.
4. You can instruct the compiler to ignore release calls and then report if anyone is sending messages to objects that would have been deallocated. This results in much better errors in the Console if it detects them.
5. Valgrind is the gold standard for finding memory bugs on Linux, and here’s a way to get it working in the iPhone Simulator.

1. Download scan-build
2. Just unpack it into any directory and add that directory to your PATH
3. Open a Terminal and cd to your project’s root directory
4. Run scan-build and view results

I've had an idea for an introductory book on programming that follows the model of "trainer" books for learning a musical instrument. Most of these books are organized like this:

1. There’s a bunch of exercises.
2. Each exercise is 1 or 2 pages.
3. There’s only a little bit of prose.
4. You do each exercise exactly, then move on.