16 maj 2006, at 22.38, Jerrod Fowkes wrote:
Well for the most part I have kept things tidy.
Tidy?
What throws a red flag in this case is that the result is about 1 -
2 meg.
Result?
The tools would be handy, however when it comes down to it, I have
an object with a retain count too high, and it must be released so
that I can get my 1-2 meg back.
Have you ever heard of autorelease pools? Think about how they affect
you when you try to debug a memory management problem by looking only
at object retain counts! Some additional reading:
<>
Keep in mind that memory leaks in the system frameworks are extremely
rare!
Also in this case It's a good thing that I did come across it with
this particular API call. I doubt those tools would have been able
to tell me that. I could be wrong though.
What you see might not be a "true" memory leak - and in that case it
should not reported as such. Alloc would still help you find
[1] which type of object that is being "leaked", and [2] where it is
"leaked".
I can only point you to the tools, but I can't force you to use them.
I can see why you hesitate to learn a new set of tools - of course
it's a bit of a pain. If you're serious about developing for the Mac,
you would need to learn about them sooner or later however (or some
one on your team would have to). In the end I definitively think that
it's worth it.
j o a r
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (Cocoa-dev (AT) lists (DOT) apple.com)
Help/Unsubscribe/Update your Subscription:
%40developershed.com
This email sent to bsdarchive (AT) developershed (DOT) com

j o a r <joar (AT) joar (DOT) comwrote: Tracking retain count is not an effective way to find memory leaks,
or other memory management problems. You should only care about
keeping your end of the Cocoa memory management agreement - ie.
basically keep retain and release balanced. Don't spend time on
peeking at things that are implementation details of the frameworks
that you use.

There are tools and techniques that are better suited for finding
memory leaks in an structured and effective way:

In particular, I like the "leaks" command line utility.

I'm not sure how easy they would be to find, but there are also a lot
of threads on this topic in the list archives:

j o a r

Well for the most part I have kept things tidy. What throws a red flag in this case is that the result is about 1 - 2 meg. After so many calls the Mac S X is brought to it's knees. The tools would be handy, however when it comes down to it, I have an object with a retain count too high, and it must be released so that I can get my 1-2 meg back. Also in this case It's a good thing that I did come across it with this particular API call. I doubt those tools would have been able to tell me that. I could be wrong though. I haven't found anything in the documentation about it messing around with the clientContext.

I don't know, but it's a possibility that this could help:

I have a loop that runs x Times. in that loop I make a call to a web service and it returns a result of 1-2 meg. So whenver it calls my delegate the CFDictionaryRef outRef actually has a retain count of 2. I have no idea why the heck it would have an extra retain count. I am certainly not retaining it for anything, and by the time it's all said and done with the call it's up to 3. Which doesn't make sense. -Jerrod

Yahoo! Messenger with Voice. Make PC-to-Phone Calls to the US (and 30+ countries) for 2/min or less.

Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (Cocoa-dev (AT) lists (DOT) apple.com)
Help/Unsubscribe/Update your Subscription:
%40developershed.com

This email sent to bsdarchive (AT) developershed (DOT) com