Memory Management

Question

How is method removeFromSuperView: really works? I got a problem of memory bad access when I want to reinit the view

- (id)init {
   if (!(self = [super init]))
      return nil;

   _mainView = [[UIView alloc] initWithFrame:[[UIScreen mainScreen] bounds]]; 
   NSLog(@"retainCount :%d", [_mainView retainCount]);
   UIButton *reInitButton = [[UIButton alloc] initWithFrame:CGRectMake(0.0f,0.0f,90.0f,35.0f)];      
   [reInitButton addTarget:self action:@selector(buttonDidTapped:) forControlEvents:UIControlEventTouchUpInside];
   [[self view] addSubView:_mainView];
   NSLog(@"retainCount :%d", [_mainView retainCount]);
   [_mainView release];
   NSLog(@"retainCount :%d", [_mainView retainCount]);

   return self;
}

- (void)buttonDidTapped:(id)sender {
   [_mainView removeFromSuperView]; //crash during second times press the button
   NSLog(@"retainCount :%d", [_mainView retainCount]);
   _mainView = [[UIView alloc] initWithFrame[[UIScreen mainScreen] bounds]];
   [[self view] addSubView:_mainView];
   NSLog(@"retainCount :%d", [_mainView retainCount]);
   [_mainView release];
   NSLog(@"retainCount :%d", [_mainView retainCount]);
}

I have NSLog every times there are any retain or alloc or release keyword. And the result is very weird.

//init
retainCount : 1
retainCount : 2
retainCount : 1
//1st time pressed button
retainCount : 1 //remove super view didn't decrease
retainCount : 2
retainCount : 1
//2nd time pressed button
retainCount : 0 //crash. Memory bad access

The weird thing is why it didn't crash on 1st time pressed??

score 3 · Answer 1 · answered May 15 '11 at 05:13

3

NEVER USE RETAINCOUNT. Sorry for putting that in caps, but I can't figure out for the life of me why people still use it. It's a faulty reference for memory management. Use instruments or similar instead.

answered May 15 '11 at 05:13

sudo rm -rf

29,408
19
102
161

ok I won't use it anymore, and what is the problem with it, I think I have release whenever it needed but it is still crash. If I remark the release in buttonDidTapped: it didn't crash but I think it is leaked – Lunayo May 15 '11 at 05:18
It's a bad idea to observe a reference count (that's a more standard term than "retain count", so maybe google that to learn about it) outside of the implementations of certain methods like `-retain` or `-release`. The problem is if the refcount is zero, the memory backing the object (including the memory backing the refcount itself) is freed and therefore it is not safe to access an object after dropping your reference, for the same reason you can't touch a buffer after `free`. Other pieces of code can also retain and release the memory as they please and you can't rely on their behaviors. – asveikau May 15 '11 at 05:23
@Lunayo: [retainCount Considered Harmful](http://stackoverflow.com/questions/5784084/) Other interesting reads on the topic: [1](http://stackoverflow.com/questions/5155559/) [2](http://stackoverflow.com/questions/5483357/) [3](http://stackoverflow.com/questions/5391479/) [4](http://stackoverflow.com/questions/3354724/) [5](http://stackoverflow.com/questions/5220902/) – jscs May 15 '11 at 05:25
I thought addSubview: retain the view, so release it after that is normal. – Lunayo May 15 '11 at 05:29
@Lunayo - It is definitely valid to release it after that, but it is NOT valid to call `-removeFromSuperView` or `-retainCount` on it after releasing it! See my answer -- you should consider moving the release to your `-dealloc`. – asveikau May 15 '11 at 05:38

asveikau · Accepted Answer · 2011-05-15T05:34:31.770

3

I think your problem is here:

[_mainView release];

You've dropped your reference to _mainView, and yet, by my reading, that's a member variable that you'll keep around and continue to invoke methods on. That's not valid. Once you've called -release, you've essentially told the system you're not going to use that object again, and you can't do anything useful with a stale pointer to that object, like you do when you call -removeFromSuperView on it later.

If you want to continue to keep _mainView around and call code on it, you need to keep a reference. Perhaps you should move the release to your object's -dealloc method. Alternatively you could -release it in the button method and re-create a new view the next time you need to.

As a helpful tip, a lot of programmers like to reset objects to NULL (or nil in objC-speak) after releasing them, as a reminder that you can't use that object again. If you -release something, you'd better mean it.

Lastly, I suggest you Google the term "reference counting" and read up on it; it's a more generic idiom than the specifics of NSObject, and it is likely to be useful to think of the basics and how you might implement this in another language, like say, C. This will help you reason better about reference counted objects.

edited May 15 '11 at 05:34

answered May 15 '11 at 05:29

asveikau

39,039
2
53
68

Note that moving the release to `dealloc`, and still creating a new view in the button's action will result in a leak. – jscs May 15 '11 at 05:42
@Josh Caswell - Yes, that's true. This is where the `nil` thing comes in handy... `if (_mainView) [_mainView release]; _mainView = /* ... */;` You'd still want a release in dealloc, though. – asveikau May 15 '11 at 05:45
If i move the release to the dealloc, what happened if I never pressed the button and then quit or back to rootViewController? It will crash? – Lunayo May 15 '11 at 05:54
And I have tried retain the _mainView in init first then release it in both buttonDidTapped: and dealloc and it cause a crash too – Lunayo May 15 '11 at 05:57
@Lunayo: Your last comment is almost there. Don't call `retain`; just call `release` in both `dealloc` and `buttonDidTapped: `. – jscs May 15 '11 at 06:18

jscs · Answer 3 · 2011-05-15T05:38:53.713

You shouldn't be accessing _mainView at that point. This may be hard to explain, so bear with me. We're going to count, but not absolute retain count, just your code's claims on the object.

You allocate memory for an object and point at it with _mainView:

_mainView = [[UIView alloc] initWithFrame:[[UIScreen mainScreen] bounds]];

You have 1 claim of ownership to that object. When you add it as the subview of another view, that view likewise makes a claim of ownership, but that's not yours, it's the view's. The fact that it makes the object in _mainView stick around is an accident, and you shouldn't rely on it. Then you release the object:

[_mainView release];

You have relinquished your ownership claim -- you now have 0 claims, and you should no longer try to access this object. You don't own it. Again, the fact that it still exists because another view is using it, and the fact that you still have a pointer to it, are accidents*, and you should not rely on them.

When it comes time to handle your button press, then, you are accessing an object over which you have no ownership:

[_mainView removeFromSuperView];

and this causes a crash, which may not be expected, but it is not unreasonable. By letting your claims of ownership go to 0, you told the system "I don't need this object anymore. I'm not going to access it after this point. If it disappears, I will not be affected." In fact, though, you do need it to stay around, and you do need to access it.

What you should do, then, is move the line:

[_mainView release];

to inside the button action, right after the call to removeFromSuperview.

*The second of which could be avoided by setting _mainView = nil; after you release it, in this case, but that won't solve the greater problem.

Memory Management

3 Answers3

Linked