guys.i'm new to iphone.
i encounter a problem.the uiimageview can't release...here is the code.
#import <UIKit/UIKit.h>
#interface imageNavView : UIImageView {
int index;
}
#property int index;
#end
#import "imageNavView.h"
#implementation imageNavView
#synthesize index;
- (id)initWithFrame:(CGRect)frameRect{
self = [super initWithFrame:frameRect];
if (self) {
// Custom initialization.
self.userInteractionEnabled=YES;
self.multipleTouchEnabled=YES;
self.opaque=YES;
self.autoresizingMask=(UIViewAutoresizingFlexibleHeight|
UIViewAutoresizingFlexibleWidth|
UIViewAutoresizingFlexibleRightMargin
|UIViewAutoresizingFlexibleLeftMargin
|UIViewAutoresizingFlexibleTopMargin
|UIViewAutoresizingFlexibleBottomMargin);
index=0;
}
return self;
}
- (void)dealloc {
NSLog(#"before image dealloc %i",[self retainCount]);-------- log is 1
[super dealloc];
NSLog(#"after image dealloc %i",[self retainCount]);-------- log is 1,why itn't bad access?
}
#end
why does the second log NSLog(#"after image dealloc %i",[self retainCount]); is 1,not a bad access,so the imageview is not released.
i can't understand,any possible way can make this happen?...any advice will be gratefull.thanks in advance!
dealloc is a call-back method while system releases an object.
The following description is a api doc of dealloc,
Instead, an object’s dealloc method is invoked indirectly through the release NSObject protocol method (if the release message results in the receiver's retain count becoming 0).
This is an excellent example of exactly why you should never call retainCount. The absolute retain count of an object is an implementation detail and it will often be of a value that makes no sense.
The behavior of calling a method after something is deallocated is entirely undefined. In this case, it may crash, it may not. If you turned on zombie detection, it would definitely crash.
Since there is absolutely no way that retainCount could ever return 0, there is no reason for object deallocation to decrement the retain count to 0.
Related
I'm new in iPhone development and after reading Apple documentation and several posts here I still have some doubts about memory management. Please, supouse this basic class:
//MyClass.h
#interface MyClass : NSObject {
NSString *varA;
OtherClass *varB;
NSString *varC;
NSString *varD;
}
#property (nonatomic, copy) NSString *varA;
#property (nonatomic, retain) OtherClass *varB;
#property (nonatomic, copy) NSString *varC;
#property (nonatomic, copy) NSString *varD;
+ (id) initClass:(NSString *)desc;
- (void) method1:(NSString *)desc;
#end
With this implementation:
//MyClass.m
#implementation MyClass
#synthesize varA;
#synthesize varB;
#synthesize varC;
#synthesize varD;
+ (id) initClass:(NSString *)desc{
self = [super init];
if( self ){
self.varA = [NSString stringWithString:desc];
self.varB = [OtherClass initClassWithAutorelease:#"a description"]; //this class return an autoreleased object
[varB aMethod:#"something"];
}
return self;
}
- (void) dealloc{
[varB aMethod:#"something"];
[varA release];
[varB release];
[super dealloc];
}
- (void) method1:(NSString *)aString{
self.varC = aString;
self.varA = [NSString stringWithString:#"new value"];
[varB aMethod:#"something"];
}
#end
At this point what I have in mind is that the instance variables with #property have to be use without self. in the init method of the class and release them without self. in the dealloc, in other methods it is convinient to use self. for all cases. So here are my doubts:
First, I suppose that if I use self.varA= in the init method the retain counter increase so I have to release it in the dealloc method, even if the object has not been created with alloc, copy or new. Or I can use only varA= in the init and I will not need to do a release. For other class methods it's better to use the setter/getter so I can use self.varA=, ... appendString:self.varA ... or ...=self.varA without problem. Is all this correct?
Second doubt, what is best in terms of memory management and simplicity, to assign to an instance variable an object in the init method with or without autorelease? If I assign to it one without autorelease I will have to dealloc it but if I use autorelease the variable could be released before I want (like the autoreleased self.varB = [OtherClass... that will be used in the dealloc method whenever the MyClass is released).
Third, do I have to dealloc all my instance variables even if I don't use them in the init method but I could use them (read/write) in other methods of the same class? (Like varC in method1 or varD that is not used).
Fourth, do I need to take care of varA after assigning the new value in method1 if I did it well in the initClass and dealloc methods? In other words, will this generate memory leaks?
Fifth, if I declare with autorelease this class like an instance variable in a ViewController (MyClass *c; ... c = [[[MyClass alloc] initClass:#"description"] autorelease];) and I set the #property, do I have to do a release if I use it with c=... instead of self.c=...? As far as I know the behavior is the same than in my example so I should use the setter/get method in the viewDidLoad or viewWillAppear and released it in the dealloc without self..
Sixth and last one, for a instance variable is varA the same that self->varA?
Thanks...
At this point what I have in mind is that the instance variables with #property have to be use without self in the init method of the class and release them without self in the dealloc
This is completely the opposite of what is true. #property just makes the variable public outside of the class. If you have another class call that object, it will look in the header file (.h file), if it doesn't see a variable by that name, it will throw a warning during compile, and an error during runtime. When using properties with synthesize (btw, your synthesize can be all on one line, doesn't really matter though, ex: #synthesize varA, varB, varC;), using self automatically retains and keeps a retain count.
- (id) initClass:(NSString *)desc{ //Note the "-" instead of the "+" here, this is an instance method, not a class method
self = [super init];
if( self ){
[self setVarA:[NSString stringWithString:desc]];
[self setVarB:[OtherClass initClassWithAutorelease:#"a description"]];
[varB aMethod:#"something"];
}
return self;
}
in other methods it is convinient to use self for all cases.
Very untrue as well. If anything, this adds another call to the call stack and makes the execution slower (by one operation, but still, one more than needed). Consider this example:
[[self varA] doStuff:#"OMG"];
versus
[varA doStuff:#"OMG"];
The 2nd one will only access one pointer, where as the first one will have to access 2 pointers to get to the same result.
First, I suppose that if I use self.varA= in the init method the retain counter increase so I have to release it in the dealloc method, even if the object has not been created with alloc, copy or new.
Untrue. The class handles the first retain, and because of this, it handles a release as well. When your class is released, it sends a release to everything it has a retain on. If you do a release in your dealloc, this will actually decrease its retain count to -1 and create a memory error. If you set the property with self.varA = someObject, then it will give it a release when your class is dealloced. If you did self.varA = [someObject retain], then you would have to do a release in the dealloc.
Or I can use only varA= in the init and I will not need to do a release.
Kinda true, you would not need to do a release because you did not do a retain. But if something else lowers the retain count to 0 on this object, there is nothing in your class that forces the object to stay alive, and it will be freed, and if you reference it, memory error.
For other class methods it's better to use the setter/getter so I can use self.varA=, ... appendString:self.varA ... or ...=self.varA without problem. Is all this correct?
No, see why above. Only use [self setVarA:newValue] if you are changing the instance of the object, the synthesize will handle the rest. Otherwise just use [varA value] to get what ever data you need.
Second doubt, what is best in terms of memory management and simplicity, to assign to an instance variable an object in the init method with or without autorelease? If I assign to it one without autorelease I will have to dealloc it but if I use autorelease the variable could be released before I want (like the autoreleased self.varB = [OtherClass... that will be used in the dealloc method whenever the MyClass is released).
If you are creating a new object in init, autorelease it. You will have to release it in your dealloc if you do just a regular alloc init. The variable will not be released before you want it because of the retain you do on it through the property. EX
-(id) init {
self = [super init];
if(self) {
[self setVarA:[[[NSString alloc] init] autorelease]]; //Sets a new instance of NSString, autoreleased
}
return self;
}
This is correct, you do not need to do anything in your dealloc. You are creating an object with a retain count of 2 (one for the alloc you did here, and 1 for the retain you do when the synthesize sets the value in your class). Now, if it autoreleases, its retain will only go down by 1, and you will still have the retain from your property, so it will not release before your class releases
-(id) init {
self = [super init];
if(self) {
[self setVarA:[[NSString alloc] init]]; //Sets a new instance of NSString
}
return self;
}
Again, you create an object with a retain count of 2. You will need to do a [varA release] in the dealloc to knock the retain count down enough for it to be released when your class is released.
Third, do I have to dealloc all my instance variables even if I don't use them in the init method but I could use them (read/write) in other methods of the same class? (Like varC in method1 or varD that is not used).
No, you do not want to send releases to freed objects. You really should never use a dealloc in my opinion, but if you decide you want to for sure, then the worst case is to check to see if the object is null, and if its not, then release it
if(varD != null)
[[self varD] release];
Fourth, do I need to take care of varA after assigning the new value in method1 if I did it well in the initClass and dealloc methods? In other words, will this generate memory leaks?
No memory leaks from NSString. This method returns an autoreleased object. When you assign a new value to [self varA], it will release the old object, and retain the new object.
Fifth, if I declare with autorelease this class like an instance variable in a ViewController (MyClass *c; ... c = [[[MyClass alloc] initClass:#"description"] autorelease];) and I set the #property, do I have to do a release if I use it with c=... instead of self.c=...? As far as I know the behavior is the same than in my example so I should use the setter/get method in the viewDidLoad or viewWillAppear and released it in the dealloc without self..
You don't need a release in either scenario. The alloc increases the release count by 1, the autorelease will decrease it to 0. If you did self.c, that would increase it to 2, and decrease to 0 (one decrease from autorelease, and one from the property) when your class is released. You do not need to do ANYTHING in dealloc.
Sixth and last one, for a instance variable is varA the same that self->varA?
Yes, they point to the same location in memory.
when ever you write "alloc, retain, copy, new" you are responsible for releasing them in the dealloc method. ex
.h file
NSString * string;
#property (nonatomic, retain)NString * string;
.m file
#synthesize string;
-(void)dealloc{
[string release];
}
hope that helps :D
I'm attaching object B via associative reference to object A. Object B observes some properties of object A through KVO.
The problem is that object B seems to be deallocated after object A, meaning its too late to remove itself as a KVO observer of object A. I know this because I'm getting NSKVODeallocateBreak exceptions, followed by EXEC_BAD_ACCESS crashes in object B's dealloc.
Does anyone know why object B is deallocated after object A with OBJC_ASSOCIATION_RETAIN? Do associated objects get released after deallocation? Do they get autoreleased? Does anyone know of a way to alter this behavior?
I'm trying to add some things to a class through categories, so I can't override any existing methods (including dealloc), and I don't particularly want to mess with swizzling. I need some way to de-associate and release object B before object A gets deallocated.
EDIT - Here is the code I'm trying to get working. If the associated objects were released prior to UIImageView being completely deallocated, this would all work. The only solution I'm seeing is to swizzle in my own dealloc method, and swizzle back the original in order to call up to it. That gets really messy though.
The point of the ZSPropertyWatcher class is that KVO requires a standard callback method, and I don't want to replace UIImageView's, in case it uses one itself.
UIImageView+Loading.h
#interface UIImageView (ZSShowLoading)
#property (nonatomic) BOOL showLoadingSpinner;
#end
UIImageView+Loading.m
#implementation UIImageView (ZSShowLoading)
#define UIIMAGEVIEW_SPINNER_TAG 862353453
static char imageWatcherKey;
static char frameWatcherKey;
- (void)zsShowSpinner:(BOOL)show {
if (show) {
UIActivityIndicatorView *spinnerView = (UIActivityIndicatorView *)[self viewWithTag:UIIMAGEVIEW_SPINNER_TAG];
if (!spinnerView) {
spinnerView = [[[UIActivityIndicatorView alloc] initWithActivityIndicatorStyle:UIActivityIndicatorViewStyleWhiteLarge] autorelease];
spinnerView.tag = UIIMAGEVIEW_SPINNER_TAG;
[self addSubview:spinnerView];
[spinnerView startAnimating];
}
[spinnerView setEvenCenter:self.boundsCenter];
} else {
[[self viewWithTag:UIIMAGEVIEW_SPINNER_TAG] removeFromSuperview];
}
}
- (void)zsFrameChanged {
[self zsShowSpinner:!self.image];
}
- (void)zsImageChanged {
[self zsShowSpinner:!self.image];
}
- (BOOL)showLoadingSpinner {
ZSPropertyWatcher *imageWatcher = (ZSPropertyWatcher *)objc_getAssociatedObject(self, &imageWatcherKey);
return imageWatcher != nil;
}
- (void)setShowLoadingSpinner:(BOOL)aBool {
ZSPropertyWatcher *imageWatcher = nil;
ZSPropertyWatcher *frameWatcher = nil;
if (aBool) {
imageWatcher = [[[ZSPropertyWatcher alloc] initWithObject:self keyPath:#"image" delegate:self callback:#selector(zsImageChanged)] autorelease];
frameWatcher = [[[ZSPropertyWatcher alloc] initWithObject:self keyPath:#"frame" delegate:self callback:#selector(zsFrameChanged)] autorelease];
[self zsShowSpinner:!self.image];
} else {
// Remove the spinner
[self zsShowSpinner:NO];
}
objc_setAssociatedObject(
self,
&imageWatcherKey,
imageWatcher,
OBJC_ASSOCIATION_RETAIN
);
objc_setAssociatedObject(
self,
&frameWatcherKey,
frameWatcher,
OBJC_ASSOCIATION_RETAIN
);
}
#end
ZSPropertyWatcher.h
#interface ZSPropertyWatcher : NSObject {
id delegate;
SEL delegateCallback;
NSObject *observedObject;
NSString *keyPath;
}
#property (nonatomic, assign) id delegate;
#property (nonatomic, assign) SEL delegateCallback;
- (id)initWithObject:(NSObject *)anObject keyPath:(NSString *)aKeyPath delegate:(id)aDelegate callback:(SEL)aSelector;
#end
ZSPropertyWatcher.m
#interface ZSPropertyWatcher ()
#property (nonatomic, assign) NSObject *observedObject;
#property (nonatomic, copy) NSString *keyPath;
#end
#implementation ZSPropertyWatcher
#synthesize delegate, delegateCallback;
#synthesize observedObject, keyPath;
- (id)initWithObject:(NSObject *)anObject keyPath:(NSString *)aKeyPath delegate:(id)aDelegate callback:(SEL)aSelector {
if (!anObject || !aKeyPath) {
// pre-conditions
self = nil;
return self;
}
self = [super init];
if (self) {
observedObject = anObject;
keyPath = aKeyPath;
delegate = aDelegate;
delegateCallback = aSelector;
[observedObject addObserver:self forKeyPath:keyPath options:0 context:nil];
}
return self;
}
- (void)dealloc {
[observedObject removeObserver:self forKeyPath:keyPath];
[keyPath release];
[super dealloc];
}
- (void)observeValueForKeyPath:(NSString *)keyPath ofObject:(id)object change:(NSDictionary *)change context:(void *)context {
[self.delegate performSelector:self.delegateCallback];
}
#end
Even larger than your -dealloc issue is this:
UIKit is not KVO-compliant
No effort has been made to make UIKit classes key-value observable. If any of them are, it is entirely coincidental and is subject to break at Apple's whim. And yes, I work for Apple on the UIKit framework.
This means that you're going to have to find another way to do this, probably by changing your view layouting slightly.
The accepted answer to this related question explains the deallocation timeline of objects. The upshot is: Associated objects are released after the dealloc method of the original object has finished.
what i think is happening in your case is this:
1) object A receives the -dealloc call, after its retain count has gone to 0;
2) the association mechanism ensures that object B gets released (which is different from deallocated) at some point as a consequence.
i.e., we don't know exactly at which point, but it seems likely to me that this kind of semantic difference is the cause of object B being deallocated after object A; object A -dealloc selector cannot be aware of the association, so when the last release on it is called, -dealloc is executed, and only after that the association mechanism can send a -release to object B...
have also a look at this post.
it also states:
Now, when objectToBeDeallocated is deallocated, objectWeWantToBeReleasedWhenThatHappens will be sent a -release message automatically.
I hope this helps explaining what you are experiencing.
As to the rest, I cannot be of much help...
EDIT: just to keep on with such an interesting speculation after the comment by DougW...
I see the risk of having a sort of cyclic dependency if the association mechanism were "broken" when releasing object A (to keep going with your example).
if the association-related code were executed from the release method (instead of dealloc), for each release you would check if the "owning" object (object A) has a retain count of 1; in fact, in such case you know that decreasing its retain count would trigger dealloc, so before doing that, you would first release the associated object (object B in your example);
but what would happen in case object B were also at its turn "owning" a third object, say it C? what would happen is that at the time release is called on object B, when object B retain count is 1, C would be released;
now, consider the case that object C were "owning" the very first one of this sequence, object A. if, when receiving the release above, C had a retain count of 1, it would first try and release its associated object, which is A;
but the release count of A is still 1, so another release would be sent to B, which still has a retain count of 1; and so on, in a loop.
If you, on the other hand, send the release from the -dealloc such cyclic dependency does not seem possible.
It's pretty contrived and I am not sure that my reasoning is right, so feel free to comment on it...
objc_getAssociatedObject() for an OBJC_ASSOCIATION_RETAIN association returns an autoreleased object. Might you be calling it earlier in the same runloop cycle / autorelease pool scope as object A is deallocated? (You can probably test this quickly by changing the association to NONATOMIC).
I've been reading all day about why views should be set to nil in viewDidUnload and released in dealloc. All the articles keep on repeating the same thing. Yes, I know the behind-the-scene instructions are different, but what are the practical differences?
var = nil
If var is a retained propery, reclaim memory the old object var pointed to.
Set var to nil.
[var release]
Reclaim memory var points to.
var now points to nothing, which is equivalent to nil
To me, both ways of reclaiming memory have the same end result. So why do one over the other? Every book out there tells me to set to nil in viewDidUnload and release in dealloc. Someone should point out the bad things that would happen if a view was released in viewDidUnload and nilled in dealloc.
.h
#import <UIKit/UIKit.h>
#interface DisclosureDetailController : UIViewController {
UILabel* label;
}
#property (nonatomic, retain) IBOutlet UILabel* label;
#end
.m
#import "DisclosureDetailController.h"
#implementation DisclosureDetailController
#synthesize label;
- (void)viewDidUnload {
self.label = nil;
// OR [self.label release];
[super viewDidUnload];
}
- (void)dealloc {
[self.label release];
// OR self.label = nil;
}
First things first, the line
[self.label release];
is absolutely wrong regardless of where you call it. You should never call -release on the results of property access. This is exactly the same as writing [[self label] release], which I hope you can recognize as being wrong.
Your code sample should look like the following:
- (void)viewDidUnload {
self.label = nil;
[super viewDidUnload];
}
- (void)dealloc {
[label release];
[super dealloc];
}
If we look at -viewDidUnload first, it's pretty simple. self.label = nil; is correct. Similarly correct would be [self setLabel:nil];. And while not quite as good, it would also be acceptable to write [label release], label = nil;. This last form isn't as good because it bypasses the setter method, which may be doing more things than simply releasing the property (e.g. it may maintain internal state that cares about the value of the property). It also bypasses KVO notifications.
The real question here is what you do in -dealloc. Many people suggest that it's perfectly fine to say self.label = nil;, and practically speaking, this will work most of the time. The problem is, the rest of the time it will cause subtle bugs. There are two things that calling the setter can do. The first is it can cause side effects in your class if the setter method is implemented manually (even if you're not implementing the setter yourself, a subclass might). The second is it can broadcast KVO notifications. Neither of these things are desired when you're in -dealloc. By releasing the ivar directly, as in [label release];, you avoid both the potential side effects and the KVO notifications.
the practical differences are as follows.
Setting the property to nil by using the property accessor will let the synthesized method take hold of your new nil property after releasing the existing property.
// we will take for granted that you synthesize this property
#property (nonatomic, retain) IBOutlet UILabel* label;
we will use the property accessor and set it to nil.
//This will in actuality set the new value of nil to the label variable after
//releasing the existing label that it had a retain count on.
self.label = nil;
next we will release it directly
//This line on the other hand will merely release the label directly.
//As soon as the label is deallocated you will have a handle to an invalid object.
//(memory space that used to be your label)
[label release];
now we will show a simplified version of the property accessor. (not to be used literally)
//Simply put the following is an pseudo equivalent of the property setter.
[label release]
label = nil;
the main point here being that the property accessor handles releasing the label that it retained. and setting it to whatever you hand it (in this case being nil)
therefore adding the following code
label = nil;
without releasing the retained object would cause a memory leak and you would have a retain count on a label you no longer have a pointer to.
Note:
another thing to take into account.
Any pointer that is nil. will be able
to accept messages. And in return they
will reply with nil. An object that
was released on the other hand, as
soon as that memory is deallocated
your message to it will most likely
throw an error. the outcome is
unpredictable. This is a good reason
for setting your properties to nil.
Not only will it handle the release
for the object that it is holding. but
it will also give you an object you
can safely message to without blowing
up.
A good point #WaltSellers
Accessing a variable -- regardless if its the property accessor or instance variable. -- After it has been released completely. Will result in "Undefined" actions. This means that the access may act ok, or it may ruin other parts of the app, or alternatively it may just blow up real fast and terminate the offending app. Basically setting the variable to nil after releasing will enable you to get past that error.
A separate tip from me
to overcome the misconception of property accessor and instance variable I just #synthesize and tell it to set a variable name.
#synthesize label = _label;
doing this allows me to differentiate self.label from its instance variable. as no longer can you access the label variable directly without the preceding _
The question is if insertSubview is retaining the views and if I'm doing it right.
I would say yes. Since I'm not using the property anymore I don't receive an EXC_BAD_ACCESS. I think when releasing the view all subviews are also released. And so mapView is over-released. I'm right or do I still have a memory management issue?
My ViewController.h
#import <UIKit/UIKit.h>
#import <MapKit/MapKit.h>
#interface MapViewController : UIViewController <MKMapViewDelegate> {
MKMapView *mapView;
// ...
}
//#property (nonatomic, retain) MKMapView *mapView;
// ...
#end
My ViewController.m
#import "MapViewController.h"
#implementation MapViewController
//#synthesize mapView;
- (void)viewDidLoad {
[super viewDidLoad];
//self.mapView=[[[MKMapView alloc] initWithFrame:self.view.bounds] autorelease];
mapView = [[MKMapView alloc] initWithFrame:self.view.bounds];
[self.view insertSubview:mapView atIndex:0];
[mapView release];
// ...
}
- (void)dealloc {
//[mapView release];
[super dealloc];
}
#end
- (void)dealloc {
//[mapView dealloc];
[super dealloc];
}
You should never call dealloc directly (save for [super dealloc]; at the end of the method). That will most assuredly cause a crash in most situations.
Since that isn't the source of your crash, you have an over-release somewhere. Use Instrument's Zombie Detection to figure out where.
Yes, you are correct on all counts:
the call to insertSubView: should be retaining the mapView that you are passing it.
releasing your reference to the mapView after you add it to the parent view
the parent view will release all the retained subviews when it is released
As a rule, you should not worry about whether or how another object will retain an instance you give it. That's up to that object to deal with; you only have to worry about making sure an instance that you intend to directly access later is retained. Don't rely on another object to keep an instance retained for you.
In your example, you have an instance (mapView) which is accessible to MapViewController but MapViewController does not have it's own retention for it. self.view could release mapView at any time for any number of reasons and you'd suddenly have bad memory there.
The Leaks instrument tells me that I have a memory leak when I use decodeObjectForKey within initWithCoder. For example:
Class.h
{
MyObject *myObject;
}
#property (nonatomic, retain) MyObject *myObject;
Class.m
#synthesize myObject
-(void)dealloc{
[myObject release];
[super release];
}
-(id)initWithCoder:(NSCoder *)decoder{
if (self = [super init]{
self.myObject = [decoder decodeObjectForKey:#"MyObject"];
}
return self;
}
Per request in the comments:
-(void)encodeWithCoder:(NSCoder *)encoder{
[encoder encodeObject:myObject forKey:#"MyObject"];
}
Leaks reports a leak of type NSCFString on the line;
self.myObject = [decoder decodeObjectForKey:#"MyObject];
As I understand it, decodeObjectForKey returns an autoreleased object. Since I immediately assign that value to the myObject property, which is specified as (nontoxic, retain) in the property definition, I retain the autoreleased object through the setter method of the myObject property. The myObject is then released in the dealloc method. I don't understand where the leak is if I understand the sequence correctly. Also why is it reported as a NSCFString when the type is MYObject?
Any thoughts would be appreciated, including if my assumptions above are correct.
Look carefully at your -dealloc method. You are calling [super release]; when you should be calling [super dealloc];.
Calling [super release] in this case is the same thing as calling [self release], since you're not overriding the -release method. If your -dealloc method is called, your object has already been fully released, so this is unnecessary. Since you are overriding the -dealloc method, you must call [super dealloc] to also free any memory allocated by the superclass.
You can refer to the NSObject documentation to see how to override dealloc correctly.