removeFromSuperview not calling dealloc of view - SOLVED
Post: #1
I have the following code:
state is one of many UIView based classes
The code is leaking memory as the current view's dealloc is not being called.
Previously (iPad iOS 3.2) I had the following at the start
and it worked with no problems.
However switching the app to a universal app was causing crashes on the release line.
Any suggestions?
Code:
if(viewController.view != nil) {
// remove view from window's subviews
[viewController.view removeFromSuperview];
}
self.screenSize = window.screen.bounds.size;
self.screenScale = window.screen.scale;
viewController.view = [[state alloc]
initWithFrame:CGRectMake(0, 0, (self.screenSize.height * self.screenScale), (self.screenSize.height * self.screenScale))
andManager:self];
[window addSubview:viewController.view];state is one of many UIView based classes
The code is leaking memory as the current view's dealloc is not being called.
Previously (iPad iOS 3.2) I had the following at the start
Code:
if(viewController.view != nil) {
// remove view from window's subviews
[viewController.view removeFromSuperview];
[viewController.view release];
}and it worked with no problems.
However switching the app to a universal app was causing crashes on the release line.
Any suggestions?
Post: #2
Well it's not being deallocated because you need that release call to balance the alloc.
Totally guessing: the reason it's crashing on the release line is probably something such as triggering a notification which is poking some other deallocated object. I would say it's a bad idea to have a deallocated object pointer (the view) assigned to the view controller, so that might be some place to start. The crash log should be very helpful.
You definitely need to balance the alloc so removing the release wasn't the correct fix.
Totally guessing: the reason it's crashing on the release line is probably something such as triggering a notification which is poking some other deallocated object. I would say it's a bad idea to have a deallocated object pointer (the view) assigned to the view controller, so that might be some place to start. The crash log should be very helpful.
You definitely need to balance the alloc so removing the release wasn't the correct fix.
Post: #3
The reason I removed the alloc is that when I investigated further it was my understanding that removeFromSuperview releases it. Of course I may have misunderstood what is in the docs
---
If the receiver’s superview is not nil, this method releases the receiver. If you plan to reuse the view, be sure to retain it before calling this method and be sure to release it as appropriate when you are done with it or after adding it to another view hierarchy.
---
Running this in the Simulator, the only message in the log is
---
If the receiver’s superview is not nil, this method releases the receiver. If you plan to reuse the view, be sure to retain it before calling this method and be sure to release it as appropriate when you are done with it or after adding it to another view hierarchy.
---
Running this in the Simulator, the only message in the log is
Code:
*** -[UIView release]: message sent to deallocated instance 0x5a6c5d0
Post: #4
I have now solved the problem.
The parent UIViewController was using a Nib file and this was causing a default UIView to be created and thus this is what was being removed and released and causing the crash.
I now implement the UIViewController's loadView method and this means there is no view set when my code runs and so does not try releasing something that does not exist.
I've no idea why it worked without loadView in the iPad only build but it did. No crashes occurred during development or testing and no crash reports have been logged from the version on the App Store.
The parent UIViewController was using a Nib file and this was causing a default UIView to be created and thus this is what was being removed and released and causing the crash.
I now implement the UIViewController's loadView method and this means there is no view set when my code runs and so does not try releasing something that does not exist.
I've no idea why it worked without loadView in the iPad only build but it did. No crashes occurred during development or testing and no crash reports have been logged from the version on the App Store.
Post: #5(Aug 11, 2010 10:34 AM)BeyondCloister Wrote: The reason I removed the alloc is that when I investigated further it was my understanding that removeFromSuperview releases it. Of course I may have misunderstood what is in the docs
---
If the receiver’s superview is not nil, this method releases the receiver. If you plan to reuse the view, be sure to retain it before calling this method and be sure to release it as appropriate when you are done with it or after adding it to another view hierarchy.
---
Correct. addSubview: retains it, and removeFromSuperview releases it. But you've still alloc'd it, so you need to balance that, which you can do immediately after addSubview. Doing it there instead of after removeFromSuperview would solve the crash as you describe. The actual bug is interesting. That would have been tricky to figure out where a view came out of nowhere.
Post: #6Quote: That would have been tricky to figure out where a view came out of nowhere.
It was tricky. It took several Red Bull fuelled readings through the UIViewController docs and my source code to track it down.
Possibly Related Threads...
| Thread: | Author | Replies: | Views: | Last Post | |
| Roll model when turning - SOLVED | MikeD | 1 | 2,278 |
Sep 29, 2010 10:55 AM Last Post: MikeD |
|
| Get model to face direction of movement - SOLVED | MikeD | 3 | 2,865 |
Sep 6, 2010 12:37 PM Last Post: MikeD |
|
| __fastcall calling convention on iPhone | Dimka | 3 | 4,899 |
Aug 21, 2010 03:35 PM Last Post: OneSadCookie |
|
| released object won't dealloc - ideas? | Gillissie | 9 | 4,374 |
Nov 17, 2009 10:27 PM Last Post: SethWillits |
|
| Calling Obj-C from C | miq01 | 7 | 4,824 |
May 1, 2009 09:19 PM Last Post: ThemsAllTook |
|