On Nov 9, 2009, at 8:16 AM, Mads Paulin wrote:
What strikes me as odd is that all Nodes in the document array are
created
and removed directly via the add and remove actions on the
treecontroller.
- I dont have a single "external" access to these objects. I would
hence
expect the controller to "clean up after itself".
It isn't a matter of the controller "cleaning up" so much as following
the memory management rules. If you follow the memory management
rules, it's the Objective-C runtime that does the cleaning up by (1)
releasing objects that you asked to be autoreleased and (2)
dealloc'ing objects when their retain count reaches zero.
The newObject method returns an object that the caller owns and is
therefore responsible for eventually releasing. If NSTreeController
uses newObject in its implementation of add:, then it is responsible
for releasing it somewhere. It sounds like it is not doing so.
In dealing with this issue, make sure you understand the concept of
objects you "own" vs. objects you don't own: <http://developer.apple.com/mac/library/documentation/cocoa/Conceptual/MemoryMgmt/MemoryMgmt.html
>. This is how you should be thinking about memory management, *not*
by looking at retain counts in isolation, because retain counts can be
misleading. That said, I think it is okay to resort to brute force
and look at when retain and release are called, and to make sure every
retain is eventually balanced by a release. You can use NSLog like
you did, or Instruments.
--Andy
Lets hope there is a couple of NSTtreeController gurus on this list
who
are able to explain the problem.
Regards,
Mads
On Nov 9, 2009, at 6:31 AM, Mads Paulin wrote:
Hi,
Yes my Document class releases the array in its dealloc method and
all Node
objects in the array are properly dealloc'ed when deallocing the
document.
However, I think the problem is unrelated to the retaining of the
array
member of the document class but rather to the retaining of elements
added
to the array via NSTreeControllers add:sender and remove:sender
class.
Yes, this is how I understood your problem.
Adding a node object through this method creates a node object in
the
document array member with a retain count of 2. The remove:sender
method
correctly removes the object from the document's array
This is the first thing I was going to suggest checking -- whether
the
object is actually removed from the array. Since it is...
but only decrements
the node object's retain count to 1 - meaning that the objects are
never
dealloc. As I see it, this is a memory leak in NSTreeController as
all "my"
external references to the Node objects are lost.
I've never used NSTreeController but something in the doc for add:
struck me as odd:
"If the receiver is in object mode newObject is called and the
returned object is added to the collection."
Since newObject returns a retained object, if this is the literal
sequence of events (call newObject, then add to collection), it sure
seems like a memory leak to me. Or arguably not, since the sequence
of events is documented, but then it's a serious API inconsistency,
since AFAIK NSArrayController doesn't have the same issue.
I do know NSTreeController is a frequently-complained-about class.
If
this is the issue you're running into, surely someone who's dealt
with
it more extensively should be able to either confirm the issue or say
it's a red herring (in which case it's a documentation bug).
--Andy
Thanks,
Mads
Mads Paulin wrote:
#import <Cocoa/Cocoa.h>
@interface MyDocument : NSDocument
{
NSMutableArray *array;
}
@property (readonly) NSMutableArray* array;
@end
All I changed in the doc impl is
@synthesize array
and
array =[ [NSMutableArray]alloc init]; in the init method.
Does your MyDocument implementation ever release array? If not,
then
what happens to the NSMutableArray and what it contains when
MyDocument is dealloc'ed? I don't think @synthesize will
synthesize
any cleanup for you.
-- GG
_______________________________________________
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/mads%40madspaulin.dk
This email sent to m...@madspaulin.dk
_______________________________________________
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/aglee%40mac.com
This email sent to ag...@mac.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 arch...@mail-archive.com
