On 13 mar 2010, at 07.36, Tobias Jordan wrote:
> I've always been having problems with Foundation's NSTimer Class when it
> comes to Memory-Management. After activating the static analyzer in Xcode
> (very useful!), it immediately reminds me of autoreleasing my instance of
> NSTimer and I thought like why is the NSTimer never being deallocated?? OKay
> so I created a demo NSTimer memory app and started testing with Instruments
> (Object Allocations Tool). In my opinion, there's a serious memory leak here
> since it's impossible to release an NSCFTimer. If I create it like that
> (should be actually autoreleased if repeat is set to NO and must be released
> manually or by calling -invalidate if repeat is set to YES):
>
> [NSTimer scheduledTimerWithTimeInterval:0.1
> target:self
>
> selector:@selector(fire:)
> userInfo:nil
> repeats:YES];
>
> I sent an -invalidate to my instance of NSTimer in -fire: but Instruments
> told me the object was still alive. This is really confusing, I think the
> instance should be released when sending an invalidate so mem-management is
> clean and fine as it is in every other Apple ObjC class.
Memory management in a shared ownership system, like the reference counted
system used in Cocoa, doesn't allow you to draw that kind of conclusion. 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.
I don't know of any memory leaks in the NSTimer class, or in Cocoa in general
when it comes with the dealing with timers. If you can reproduce something that
you suspect being a problem with Cocoa, please either post some sample code, or
file a bug report:
<http://developer.apple.com/bugreporter/>
> Since that didn't work I added a -release after invalidating the timer. This
> results in an EXC_BAD_ACESS (Invalid address) although its retain count was
> 1. I guess there's something else going wrong inside the NSTimer.
With all respect, if you thought that would be an OK "solution", then I think
that you should go back and review the memory management documentation.
> Unfortunately, the Apple NSTimer docs don't say anything about mem managment
> (nothing in discussion or sth like that)…
The API reference documentation calls out exceptions, not things that just
follow the general memory management rules. That said, there are two things
about timers that you need to know and understand, but they are both called out
in the documentation:
"Note in particular that run loops retain their timers"
"The target object is retained by the timer and released when the timer
is invalidated"
In addition, there's a separate programming topic on timers in the conceptual
documentation:
<http://developer.apple.com/mac/library/documentation/Cocoa/Conceptual/Timers/Articles/usingTimers.html#//apple_ref/doc/uid/20000807>
...and at the end of that page they also explicitly calls out memory management
aspects to keep in mind.
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
