On Feb 22, 2013, at 9:42 AM, Matt Neuburg wrote: > On Sun, 17 Feb 2013 12:16:47 -0600, Ken Thomases <k...@codeweavers.com> said: >> On Feb 17, 2013, at 11:50 AM, Matt Neuburg wrote: >> >>> On Sat, 12 Jan 2013 11:13:13 +0000, Mike Abdullah >>> <cocoa...@mikeabdullah.net> said: >>>> >>>> The allocations instrument can show you all presently allocated objects. >>>> Find the object(s) you're interested in from that list and you can view >>>> its history of being retained and (auto)released, to figure out what is >>>> still holding onto it. >>> >>> Actually, Instruments is no help in figuring out "what is still holding >>> onto it". That's not entirely unreasonable, since in a very real sense *no* >>> object is "holding onto" anything; there are only messages and the object's >>> own internal retain count. >> >> Well, you can't figure out what object is holding onto another object, but >> you can figure out which _body of code_ is holding onto an object. >> >>> But it sure would be nice if Instruments did give more info about this, so >>> that one could try to track down which retains are balanced by which >>> releases (and which retains, therefore, are unbalanced). >> >> Well, Instruments can no more divine which release balances which retain as >> it can know what object might "hold" what other object. > > The words "which body of code is holding onto an object" don't have any > meaning to me, and I don't think they have any meaning to you either. You're > just waving your hands. If I wanted to wave my hands I wouldn't be using > Instruments.
It means a class's implementation or a module. It's an organizational notion so, no, it doesn't have a precise syntactical definition. It's the same sort of thing as "separation of responsibilities". If it doesn't have meaning for you, I don't know how to help you. > Some specific object did send "retain". Objects don't send messages. Code sends messages. The implementations of methods of classes send messages, as can straight functions. (As an aside, it's a pretty common question from new programmers – not saying you're one – to want to know, when implementing a method, "which object sent the message?" More experienced programmers understand that that isn't how things work and that information isn't available and isn't even always meaningful. For the same reasons, it's not productive to try to think about, from within an implementation of -retain or -release, "which object retained/released this object?" because it's the same question. This point of view, from within the implementation of -retain and -release, is roughly that which is available to Instruments.) > It is that specific object's responsibility eventually to send "release". Nope. It is the responsibility of the related code. > That's how Cocoa memory management works. Nope. Cocoa includes conventions for one part of the code to pass ownership to other parts of the code. Methods with "new" or "copy" in their name return ownership to their callers, for example. Also, Cocoa memory management isn't the only kind of memory management that's necessary. For example, Core Foundation memory management can interact with Cocoa memory management through toll-free bridging. I hope you see that Core Foundation memory management can't be assigned to objects. > Instruments *can* know, and *should* tell me, what specific object that is. Nope. It can only know which code is responsible. Just because that code may be a method implementation doesn't mean Instruments knows what object that belongs to. The code could also not belong to any object and that's valid in Cocoa memory management. It's also possible that the code which is supposed to release something is not part of the same class as the code which allocated it (ownership was transferred). > I wouldn't be here (i.e. using this aspect of Instruments) if this were not > the very problem I'm having, i.e. some specific object is not fulfilling its > responsibilities and I need to work out who it is. The fact that Instruments > doesn't tell me this is not just some mild forgivable accident. It is Teh > Suck. Well, I'm sorry that you're frustrated but many aspects of development require the application of human intelligence and can't be automated. This is one of them. If you actually go through the exercise of reviewing an object's retain/release history and matching up the retains and releases, you'll pretty quickly see that it's a difficult problem requiring an understanding of the code at a pretty high level. If you believe that Instruments could be made to automate it, you should describe an algorithm that could do it. I don't think you'll be able to without invoking magical artificial intelligence. Regards, Ken _______________________________________________ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
