Re: Memory Leaks in CocoaEcho Sample
Re: Memory Leaks in CocoaEcho Sample
- Subject: Re: Memory Leaks in CocoaEcho Sample
- From: Bill Bumgarner <email@hidden>
- Date: Wed, 22 Oct 2008 13:48:17 -0700
On Oct 22, 2008, at 1:35 PM, Jens Beuckenhauer wrote:
Hello,
In general, the retain count is entirely meaningless. The retain
count of any given object, especially objects that were created by
or have passed through the Apple provided frameworks, may be
seemingly random due to the internal implementation details of the
class or of the frameworks. Caching, singletons, and any of a
number of optimizations could impact the retain count.
Frankly, -retainCount should be deprecated and eliminated.
If you are trying to find a leak, then use one of the tools on the
system designed for exactly that -- leaks, Object Graph in
Instruments for GC, Object Alloc for non-GC, etc...
In my special case (the memory leak in the CocoaEcho sample) I used
Instruments with the "leaks" instrument and it shows up several
memory leaks. They seem to come from the openstream: and
closestream: methods.
Is the retain in these methods right after I got the streams with -
getInputStream:outputStream: or is it wrong? How can I test it to go
sure?
The retains in -openStreams are balanced by the releases in -
closeStreams. Similarly, the streams are retained/released in a
balanced fashion within the server. So, unless the server is never
shutting down, that isn't the source of your leak -- there must be an
unbalanced -retain coming from somewhere.
The Leaks instrument can tell you where all -retain/-releases were
invoked from. You should see an unbalanced -retain.
b.bum
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden