views:

234

answers:

3

I've got an issue with an object not being deallocated in objective-c. I'm pretty certain this is because it is being retained somewhere, but I don't know where (checking retainCount where it ought to be 0 returns a 1). I've gone through my code many times but fail to see what's retaining it that I don't release. Might even be a bug in the frameworks I'm using.

How would you deal with something like this? I thought maybe you could search through the memory and see what's pointing to this object, making it considerably easier to figure out why it is like this, but I'm not quite sure how to achieve that. Maybe another solution?

+3  A: 

Have you tried Instruments?

Chris McCall
Wow, thanks. I had totally forgotten about that app. And strange as it is, as soon as I started debugging my program using instruments, and failed to see any errors, dealloc started to be called. :s
quano
O man Instruments if fkn awesome! Haven't really used it until now but it is extremely helpful.
quano
+1  A: 

Override -retain and -release, then set breakpoints to see who's calling them.

Darren
I saw this solution somewhere, and it seems like a very simple and good solution. But, how do I know who's calling release and retain? The only arg is self?
quano
This can help figure out who **is** calling them, but not so much with who **isn't** — you still have to figure that out on your own. The Xcode Static Analyzer is a much more elegant and painless approach, and works well for _most_ cases, since most leaks result from allocating and not properly releasing an object before handing it to someone else, etc.
Quinn Taylor
You've asked "But, how do I know who's calling release and retain?" If you set breakpoints in -retain and -release then when those breakpoints are hit you can examine the call stack which will show you who called retain/release.
jarmod
+7  A: 

Instruments is great, and can pick up on leaked objects if and when they are leaked, but in cases like these I suggest you first use the Xcode Static Analyzer, new in Xcode 3.2 with Snow Leopard. (If you're on Leopard, you can use the command-line version.) Static analysis allows you to find a great many problems without even executing your code, and in many cases is much easier to use than Instruments.

Quinn Taylor
I hear clang doesn't work with obj-c++. Does Xcode Static Analyzer do that? If it does I'm seriously considering upgrading to Snow Leopard.
quano
The Xcode static analyzer **is** the Clang Static Analyzer, just with better IDE integration, and both use Clang as a front-end parser. Clang doesn't **yet** work with C++, but progress is steadily being made. http://clang.llvm.org/cxx_status.html Since Clang itself is written in C++, I'm sure you can imagine how committed the authors are to supporting the language. :-)
Quinn Taylor
However, it should be noted that the Objective-C support is wonderful, and that one tool alone can save you countless hours tracking down the source of memory leaks.
Quinn Taylor
Well I think I'll stick to Instruments for now, and upgrade to Snow Leopard later. :) Thanks for the tip.
quano