Strange memory error dealloc/release

Question

I've been experiencing a weird error in my Objective-C program for iPhone. Here's what happens:

I get a EXC_BAD_ACCESS crash.
Fine, the zombies kick in and the log tells me it's about a CFNumber that gets a release, but is already deallocated. Still no tough cookie.
I keep debugging until I hit a block with two NSNumbers. There are no CFNumbers in my code, so I reckon it's these lines.
I try retaining them, with no success, even filling them with nil, overwriting them with new values, etc. Still nothing.
I comment the lines out. Now the log keeps bugging about the same CFNumber, but now is being sent a "doubleValue" (instead of "release") while it's already deallocated. There is no "doubleValue" in my code.

What's going on here? Are the zombies messing with my code? I'm on a dead end here. Any help is greatly appreciated.

Kind regards,

Reinder

Guess something else autoreleased and that memory is being occupied by something else which comes up in your log. — Bourne
I'm unable to help with most of the problem, but CFNumbers and NSNumbers are toll-free bridged, so they're exactly the same thing, to the point where they can't be distinguished at the machine level. A pointer to one is also a pointer to the other. So you're right to investigate NSNumber instances. — Tommy
Have you run the Analyzer? Any warnings? If you have and it looks good, next step is to profile with Instruments using leaks. — Max MacLeod
Okay folsk, worked it out. Apparently I was just overwriting a property (which was retained), with a non-retained variable. Hence, the "already deallocated" errors. So, that said, I analyzed the code, fixed all the bad releases, dropped the bad habit, learned a lot. Thanks! — Reinder de Vries

Daryl Teo Daryl Teo · Accepted Answer · 2011-09-20T13:26:31

Sadly, not much we can do without code.

Here are some general principles to keep note of, and will make your life easier.

You refers to the current class.

if you need to use it for a long period of time, retain it.
if you don't need it at the end of a function, don't keep it (alloc, then release at the end) if you did not retain it, do not release it.
if you did not alloc it, do not release it.
if you are returning an object you allocated, and thus will lose control of it, autorelease (pretty much what it was designed for). This is in line with principle 3 and 4, as it means the calling class will need to make the decision to retain or release it.

Hope this helps you pinpoint the problem.