Re: Memory Leaks in CocoaEcho Sample

2008-10-23 Thread Marco Masser
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

Re: Memory Leaks in CocoaEcho Sample

2008-10-23 Thread Ken Ferry
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

Re: Memory Leaks in CocoaEcho Sample

2008-10-22 Thread Marco Masser
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

Re: Memory Leaks in CocoaEcho Sample

2008-10-22 Thread Nick Zitzmann
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

Re: Memory Leaks in CocoaEcho Sample

2008-10-22 Thread Marco Masser
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

Re: Memory Leaks in CocoaEcho Sample

2008-10-22 Thread Bill Bumgarner
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

Re: Memory Leaks in CocoaEcho Sample

2008-10-22 Thread Nick Zitzmann
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

Re: Memory Leaks in CocoaEcho Sample

2008-10-22 Thread Clark Cox
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

Re: Memory Leaks in CocoaEcho Sample

2008-10-22 Thread Jens Beuckenhauer
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

Re: Memory Leaks in CocoaEcho Sample

2008-10-22 Thread Bill Bumgarner
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

Re: Memory Leaks in CocoaEcho Sample

2008-10-22 Thread Marco Masser
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

Re: Memory Leaks in CocoaEcho Sample

2008-10-22 Thread Gary L. Wade
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,

Re: Memory Leaks in CocoaEcho Sample

2008-10-22 Thread Jens Beuckenhauer
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.

Re: Memory Leaks in CocoaEcho Sample

2008-10-22 Thread Gary L. Wade
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];

Re: Memory Leaks in CocoaEcho Sample

2008-10-22 Thread Jens Beuckenhauer
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];