Hi Joar,
Thanks a lot for taking the time to respond to this request! Let me
explain what made me write to this cocoa list and think NSTimer's got
a memory leak:
When reading through all the class documentations from Apple I often
see some notes in the discussion group that say something like:
'Returns an autoreleased object … ' or the opposite so I know whether
I have to take care of releasing the object or not. I like and
understand the reference counting system. I guess it means when
sending a retain I tell the object: Hey, I need you, don't go away
until I tell you to do. That's why one class can always send only one
retain or one release. So it is quite clear that it's more than not
okay to send a double retain or release. ;-) I did this while
experimenting with the NSTimer class to find out how it's working. I
sent a double-release to see if there's really one release somwhere
else missing and I was actually really confused about the crash. After
getting the solution -- that it's just some caching -- it has been eye
opening for me, this explains NSTimers behavior. What made me think it
is a bug was actually only the fact that instruments told me the
object is always still alive and the 'missing' note in the
documentations that tell me I don't need to release it because of some
caching techniques. I guess you're right, I was just thinking too
quickly, most users don't do these tests in Instruments, they rely on
what's written in the docs :-), I don't see any bugs in NSTimer anymore.
Have you filed a bug report on this issue?
Not me but I am pretty sure a friend of mine did.
The assumption that an object would get deallocated immediately as
soon as you have balanced your memory management calls can be true
in specific cases, but not in general - In particular when dealing
with classes that you don't own, and when dealing with shared objects.
No no, I don't assume that all objects are getting deallocated
immediately provided that its caching or whatever system is really
helpful and makes sense. In IKImageBrowserView's case it's just
filling up my whole RAM and then crashed because of missing memory,
that's what I simply don't want. :-(
So I guess it is really the missing 'NSTimer is caching its instances'
line that confused me so sorry about that and thanks for your help!
Best regards,
Tobias Jordan.
On Mar 13, 2010, at 6:55 PM, Joar Wingfors wrote:
On 13 mar 2010, at 09.08, Tobias Jordan wrote:
Yes, don't get me wrong, I trust the Apple docs, of course but I
also know it's possible they are doing something wrong. I don't
remember all cases but it always starts like this: I see
something's not being freed, I try to free it, it doesn't work, I
do a search on it and notice there are a lot of other developers
saying this is an Apple bug and sending a bug report.
While it's impossible to completely rule out problems in Cocoa, it
is as a general rule not productive to start out by assuming that a
discovered problem should be caused by a problem in Cocoa. The Cocoa
frameworks receive so much testing, and have so many clients, that
it is far more likely that any issues are to be found in your own
software. That said, if you identify a bug in Cocoa, or its
documentation, we very much welcome your bug reports:
<http://developer.apple.com/bugreporter/>
It is great that you're looking at your software product in
Instruments to make sure that it behaves correctly and as expected -
More people should do that! Keep in mind though, and considering the
attempts at fixing found problems that you mentioned at the
beginning of this thread, that you can't propose solutions that
doesn't comply with the general memory management guidelines (for
example, you can't add extra calls to "-release" simply because you
find an object that you expected to have been deallocated).
One example is the IKImageBrowserNSImageRepresentationType used for
the IKImageBrowserView. No one knows whether it's some kind of a
very clever caching but for now it is not possible to completely
remove the image of an NSImage-browserItem within an
IKImageBrowserView.
What that means is -- I load like 100 images into my browser view,
remove them, add another 200, remove them and the memory says 500
MBs or more. And that's nothing you can say 'Oh, don't worry it's
all ok' about since my app's crashed this way. ;-)
I guess, the reasons all other IKImageBrowserViews used in public
3rd party apps are working are a) the few images are too small for
being a problem or b) the IKImageBrowserPathRepresentationType has
been used which does the releasing very well.
Have you filed a bug report on this issue?
j o a r
_______________________________________________
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
