Re: Memory Leaks in CocoaEcho Sample
Then the bug is somewhere in your changes. The only thing you
should do is remove the retain calls. If you also remove the
release calls, you will still have the memory leaks.
Here's what openStreams should look like:
- (void)openStreams {
[inputStream setDelegate:self];
[outputStream setDelegate:self];
[inputStream scheduleInRunLoop:
[NSRunLoop currentRunLoop] forMode:NSDefaultRunLoopMode];
[outputStream scheduleInRunLoop:
[NSRunLoop currentRunLoop] forMode:NSDefaultRunLoopMode];
[inputStream open];
[outputStream open];
}
Here's what closeStreams should look like:
- (void)closeStreams {
[inputStream close];
[outputStream close];
[inputStream removeFromRunLoop:
[NSRunLoop currentRunLoop] forMode:NSDefaultRunLoopMode];
[outputStream removeFromRunLoop:
[NSRunLoop currentRunLoop] forMode:NSDefaultRunLoopMode];
[inputStream setDelegate:nil];
[outputStream setDelegate:nil];
[inputStream release];
[outputStream release];
inputStream = nil;
outputStream = nil;
}
I have done exactly what you wrote above in a freshly dezipped
CocoaEcho Project. Running it first with the retain and then
without. It didn't work. This morning, I tried it again and it
worked?!? I think I forgot to clean the build or something like
that... Thanks for your help
Still, my question remains: Is there a rule of thumb for the memory
management of object returned by reference? NSError and NSGradient
autorelease their objects, NSNetService does not. Because the docs
don't say anything about this (with the exception of the Error
Handling Programming Guide), how should one know if an object should
be retained or not?
Marco
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to [EMAIL PROTECTED]
Re: Memory Leaks in CocoaEcho Sample
Hi Marco,
Still, my question remains: Is there a rule of thumb for the memory
management of object returned by reference? NSError and NSGradient
autorelease their objects, NSNetService does not. Because the docs don't say
anything about this (with the exception of the Error Handling Programming
Guide), how should one know if an object should be retained or not?
The rule for objects returned by reference is the same as the rule for
objects returned any other way: -copy, -alloc, -retain and -new methods
transfer ownership. Nothing else does unless specially documented. If you
think there's a leak with an object returned by reference, please file a
bug.
I see that there was a leak in -getInputStream:outputStream:, but it was
fixed for apps linked on or after the 10.4 SDK. This was probably in the
Foundation release notes, but the older Foundation release notes don't seem
to be up anymore.. rdar://problem/6313911.
-Ken
Cocoa Frameworks
On Thu, Oct 23, 2008 at 1:52 AM, Marco Masser [EMAIL PROTECTED]wrote:
Then the bug is somewhere in your changes. The only thing you should do is
remove the retain calls. If you also remove the release calls, you will
still have the memory leaks.
Here's what openStreams should look like:
- (void)openStreams {
[inputStream setDelegate:self];
[outputStream setDelegate:self];
[inputStream scheduleInRunLoop:
[NSRunLoop currentRunLoop] forMode:NSDefaultRunLoopMode];
[outputStream scheduleInRunLoop:
[NSRunLoop currentRunLoop] forMode:NSDefaultRunLoopMode];
[inputStream open];
[outputStream open];
}
Here's what closeStreams should look like:
- (void)closeStreams {
[inputStream close];
[outputStream close];
[inputStream removeFromRunLoop:
[NSRunLoop currentRunLoop] forMode:NSDefaultRunLoopMode];
[outputStream removeFromRunLoop:
[NSRunLoop currentRunLoop] forMode:NSDefaultRunLoopMode];
[inputStream setDelegate:nil];
[outputStream setDelegate:nil];
[inputStream release];
[outputStream release];
inputStream = nil;
outputStream = nil;
}
I have done exactly what you wrote above in a freshly dezipped CocoaEcho
Project. Running it first with the retain and then without. It didn't work.
This morning, I tried it again and it worked?!? I think I forgot to clean
the build or something like that... Thanks for your help
Still, my question remains: Is there a rule of thumb for the memory
management of object returned by reference? NSError and NSGradient
autorelease their objects, NSNetService does not. Because the docs don't say
anything about this (with the exception of the Error Handling Programming
Guide), how should one know if an object should be retained or not?
Marco
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
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:
http://lists.apple.com/mailman/options/cocoa-dev/kenferry%40gmail.com
This email sent to [EMAIL PROTECTED]
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to [EMAIL PROTECTED]
Re: Memory Leaks in CocoaEcho Sample
I'm just building my own application based on the CocoaEcho sample from Apple. But the CocoaEcho Client is full of memory leaks. These leaks occur, when you select and deselect a CocoaEchoServer some times by clicking on them and again next to them Leaked Objects are: SCNetworkReachability GeneralBlocks NSCFDictionaries NSCFData NSCFInputStream NSCFOutputStream All points to the openstream: and closestream: methods but I am not so skilled to find the error with the help of instruments and the debugger. Does someone know if there is something wrong in the CocoaEchoClient code or if the error is in the Cocoa frameworks itself? I've built a networking framework some time ago and used the CocoaEcho example as a starting point. Some of the sample code is still present and I just realised that I'm using the exact same -openStreams method, just without the two -retain messages for the inputStream and outputStream. Additionally, I just verified that doing just that in the CocoaEcho example gets rid of the memory leaks. According to Cocoa conventions, methods starting with -get... return values by reference, but I can't find anything that talks about memory management when using such methods. Therefore, I would assume the normal rules apply and the values should be autoreleased (even though we are not really talking about return values per se). The streams you get by using -getInputStream:outputStream: have a retain count of 1 and are not autoreleased. I'd say it's either a bug in the framework or rather a weak spot in the documentation. Marco P.S.: I just tested NSGradient's -getColor:location:atIndex: method (the only one I could find that returns an object by reference) and here too, the first parameter (an NSColor **) has a retain count of 1 and is not autoreleased. I'd say there's something amiss in the docs and the CocoaEcho sample is wrong. ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: Memory Leaks in CocoaEcho Sample
On Oct 22, 2008, at 1:05 PM, Marco Masser wrote: P.S.: I just tested NSGradient's -getColor:location:atIndex: method (the only one I could find that returns an object by reference) and here too, the first parameter (an NSColor **) has a retain count of 1 and is not autoreleased. How do you know that it isn't autoreleased? Nick Zitzmann http://www.chronosnet.com/ ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: Memory Leaks in CocoaEcho Sample
P.S.: I just tested NSGradient's -getColor:location:atIndex: method (the only one I could find that returns an object by reference) and here too, the first parameter (an NSColor **) has a retain count of 1 and is not autoreleased. How do you know that it isn't autoreleased? I don't know of any way to look into an autorelease pool, if you mean that : ) I just made an NSColor ivar and retained it after calling - getColor:location:atIndex: and took a look on its retain count in a second method that was called after the NSAutoreleasePool had been drained (i.e. I took a look at the retain count after pressing a button). That way, all -autorelease messages must have been dealt with. In the second method, the count was 2. After removing the - retain following the -getColor..., the retain count in the second method was 1. Marco ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: Memory Leaks in CocoaEcho Sample
On Oct 22, 2008, at 12:54 PM, Marco Masser wrote: I don't know of any way to look into an autorelease pool, if you mean that : ) I just made an NSColor ivar and retained it after calling - getColor:location:atIndex: and took a look on its retain count in a second method that was called after the NSAutoreleasePool had been drained (i.e. I took a look at the retain count after pressing a button). That way, all -autorelease messages must have been dealt with. In the second method, the count was 2. After removing the - retain following the -getColor..., the retain count in the second method was 1. 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... Now... in this particular case... How can you look at the retain count of an object after the autorelease pool was drained without it being retained by something? Didn't you have to retain it to keep the NSColor iVar around? b.bum smime.p7s Description: S/MIME cryptographic signature ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: Memory Leaks in CocoaEcho Sample
On Oct 22, 2008, at 1:54 PM, Marco Masser wrote: I don't know of any way to look into an autorelease pool, if you mean that : ) I just made an NSColor ivar and retained it after calling - getColor:location:atIndex: and took a look on its retain count in a second method that was called after the NSAutoreleasePool had been drained (i.e. I took a look at the retain count after pressing a button). That way, all -autorelease messages must have been dealt with. In the second method, the count was 2. After removing the - retain following the -getColor..., the retain count in the second method was 1. Retain counts != memory leaks. If you make sure zombies are turned off (which they are, by default), and run the code in MallocDebug, and MallocDebug does not report a leak after the code is run, then the memory was not leaked. But if it does, and you're sure zombies are off, then you just might have found a leak in a system framework, and should probably report it. It's generally good advice to just ignore retain counts and follow the memory management rules as written. Also, memory leaks in system frameworks are quite rare. There were some real leaks in the past (e.g. the NSCalendar and NSDateFormatter classes were very leaky in Tiger), but they were fixed a while ago. Nick Zitzmann http://www.chronosnet.com/ ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: Memory Leaks in CocoaEcho Sample
On Wed, Oct 22, 2008 at 12:54 PM, Marco Masser [EMAIL PROTECTED] wrote: P.S.: I just tested NSGradient's -getColor:location:atIndex: method (the only one I could find that returns an object by reference) and here too, the first parameter (an NSColor **) has a retain count of 1 and is not autoreleased. How do you know that it isn't autoreleased? I don't know of any way to look into an autorelease pool, if you mean that : I just made an NSColor ivar and retained it after calling -getColor:location:atIndex: and took a look on its retain count in a second method that was called after the NSAutoreleasePool had been drained (i.e. I took a look at the retain count after pressing a button). That way, all -autorelease messages must have been dealt with. In the second method, the count was 2. After removing the -retain following the -getColor..., the retain count in the second method was 1. That still means nothing, you rarely get useful information from inspecting an object's retain count. You should just follow all of the normal memory management rules, and forget that the retainCount method even exists. In this case, you are not responsible for releasing the color that you get back from -getColor:location:atIndex:. -- Clark S. Cox III [EMAIL PROTECTED] ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: Memory Leaks in CocoaEcho Sample
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? I'm not really sure about this. Thanks for your help Jens ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: Memory Leaks in CocoaEcho Sample
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 smime.p7s Description: S/MIME cryptographic signature ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: Memory Leaks in CocoaEcho Sample
Sorry about any confusion that I may have caused! The color I got from the NSGradient's -getColor:location:atIndex: actually was autoreleased, but the NSGradient was not. Therefore, the color always had an retain count of 1. Sorry about that. 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... I didn't try to find a leak with this NSGradient method, I tried to find a rule of thumb for the memory management for objects created and returned by reference. Apart from NSNetService's - getInputStream:outputStream: and NSGradient's - getColor:location:atIndex:, I couldn't find such a case (there are plenty of methods returning primitives or C-structs by reference, though). Now that I think of it, any method using an NSError** might be worth looking into: In this case, the basic memory management rules apply. The Error Handling Programming Guide is clear about this: [...] you should send autorelease to [the NSError object] before you return it to the caller. http://developer.apple.com/documentation/Cocoa/Conceptual/ErrorHandlingCocoa/CreateCustomizeNSError/chapter_4_section_4.html Now... in this particular case... How can you look at the retain count of an object after the autorelease pool was drained without it being retained by something? Didn't you have to retain it to keep the NSColor iVar around? I just made an NSColor ivar and retained it after calling - getColor:location:atIndex: and took a look on its retain count in a second method that was called after the NSAutoreleasePool had been drained (i.e. I took a look at the retain count after pressing a button). That way, all -autorelease messages must have been dealt with and what remains are the real retains. ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: Memory Leaks in CocoaEcho Sample
To move beyond the memory leaks in an untouched version of EchoClient, the only thing you need to do is remove the retain calls in openStreams. The call to -[NSNetService getInputStream:outputStream:] calls CFStreamCreatePairWithSocketToNetService, which is a create function. To verify this, the memory leak will be exacerbated every time you select and deselect a service. Hello, 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. So I think now I got it, for example if there is a line 48 there should be another line -48, right? Then it's balanced, and it's not necessarily the last line? There are several leaks, and I think one unbalanced part should then be getinputstream:outputstream:, and -openstreams: Simply deleting the two retain lines in the openstreams: didn't work... Jens ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: Memory Leaks in CocoaEcho Sample
Hello, To move beyond the memory leaks in an untouched version of EchoClient, the only thing you need to do is remove the retain calls in openStreams. The call to -[NSNetService getInputStream:outputStream:] calls CFStreamCreatePairWithSocketToNetService, which is a create function. To verify this, the memory leak will be exacerbated every time you select and deselect a service. I tried that, but the leaks are still there if I select and deselect the service several times. (Not the first time, but later on)... Jens ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: Memory Leaks in CocoaEcho Sample
Then the bug is somewhere in your changes. The only thing you should do is
remove the retain calls. If you also remove the release calls, you will still
have the memory leaks.
Here's what openStreams should look like:
- (void)openStreams {
[inputStream setDelegate:self];
[outputStream setDelegate:self];
[inputStream scheduleInRunLoop:
[NSRunLoop currentRunLoop] forMode:NSDefaultRunLoopMode];
[outputStream scheduleInRunLoop:
[NSRunLoop currentRunLoop] forMode:NSDefaultRunLoopMode];
[inputStream open];
[outputStream open];
}
Here's what closeStreams should look like:
- (void)closeStreams {
[inputStream close];
[outputStream close];
[inputStream removeFromRunLoop:
[NSRunLoop currentRunLoop] forMode:NSDefaultRunLoopMode];
[outputStream removeFromRunLoop:
[NSRunLoop currentRunLoop] forMode:NSDefaultRunLoopMode];
[inputStream setDelegate:nil];
[outputStream setDelegate:nil];
[inputStream release];
[outputStream release];
inputStream = nil;
outputStream = nil;
}
Hello,
To move beyond the memory leaks in an untouched version of
EchoClient, the only thing you need to do is remove the retain calls
in openStreams. The call to -[NSNetService
getInputStream:outputStream:] calls
CFStreamCreatePairWithSocketToNetService, which is a create
function.
To verify this, the memory leak will be exacerbated every time you
select and deselect a service.
I tried that, but the leaks are still there if I select and deselect
the service several times. (Not the first time, but later on)...
Jens
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to [EMAIL PROTECTED]
Re: Memory Leaks in CocoaEcho Sample
Hello,
Then the bug is somewhere in your changes. The only thing you
should do is remove the retain calls. If you also remove the
release calls, you will still have the memory leaks.
Here's what openStreams should look like:
- (void)openStreams {
[inputStream setDelegate:self];
[outputStream setDelegate:self];
[inputStream scheduleInRunLoop:
[NSRunLoop currentRunLoop] forMode:NSDefaultRunLoopMode];
[outputStream scheduleInRunLoop:
[NSRunLoop currentRunLoop] forMode:NSDefaultRunLoopMode];
[inputStream open];
[outputStream open];
}
Here's what closeStreams should look like:
- (void)closeStreams {
[inputStream close];
[outputStream close];
[inputStream removeFromRunLoop:
[NSRunLoop currentRunLoop] forMode:NSDefaultRunLoopMode];
[outputStream removeFromRunLoop:
[NSRunLoop currentRunLoop] forMode:NSDefaultRunLoopMode];
[inputStream setDelegate:nil];
[outputStream setDelegate:nil];
[inputStream release];
[outputStream release];
inputStream = nil;
outputStream = nil;
}
I have done exactly what you wrote above in a freshly dezipped
CocoaEcho Project. Running it first with the retain and then without.
It didn't work. This morning, I tried it again and it worked?!? I
think I forgot to clean the build or something like that... Thanks for
your help
Jens
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to [EMAIL PROTECTED]
