This question already has answers here:
Closed 10 years ago.
Possible Duplicate:
Why is object not dealloc'ed when using ARC + NSZombieEnabled
I've got a very strange issue I'm seeing at the moment in a project. Put simply I have ViewA which owns ViewB (strong property). ViewA creates its ViewB in its initialiser. Both objects are subclasses of UIView.
I have overridden dealloc in both and put a log line and a break point to see if they get hit. It seems that ViewA's dealloc is being hit but not ViewB's. However if I put in a self.viewB = nil in the dealloc of ViewA then it is hit.
So basically it's something like this:
#interface ViewA : UIView
#property (nonatomic, strong) ViewB *viewB;
#end
#implementation ViewA
- (id)initWithFrame:(CGRect)frame {
if (self = [super initWithFrame:frame]) {
self.viewB = [[ViewB alloc] initWithFrame:self.bounds];
[self addSubview:self.viewB];
}
return self;
}
- (void)dealloc {
//self.viewB = nil; ///< Toggling this commented/uncommented changes if ViewB's dealloc gets called.
NSLog(#"ViewA dealloc");
}
#end
What I can't understand is why nil-ing viewB out makes a difference. If something else is holding onto viewB then it should make absolutely no difference if I nil it out or not here. And it shouldn't make a difference to the number of releases that ARC adds in either.
I can't seem to reproduce it in a minimal test case as yet, but I'm working on it. And I can't post the actual code I'm seeing this in unfortunately. I don't see that being an issue though because it's more the point that nil-ing it out shouldn't make a difference that I am confused by.
Can anyone see anything I am overlooking or give advice about where to look for debugging this problem?
Update:
I've found the problem. It appears that it's only a problem when NSZombieEnabled is set to YES. Well that is entirely mad and has to be a bug surely. Zombies should not affect how this works as far as I know. The objects should still go through the dealloc method. And what's more, it's just mad that it works if I nil out viewB in ViewA's dealloc.
I've found that this appears to be a bug in the iOS implementation of zombies. Consider the following code:
#import <Foundation/Foundation.h>
#interface ClassB : NSObject
#end
#implementation ClassB
- (id)init {
if ((self = [super init])) {
}
return self;
}
- (void)dealloc {
NSLog(#"ClassB dealloc");
}
#end
#interface ClassA : NSObject
#property (nonatomic, strong) ClassB *b;
#end
#implementation ClassA
#synthesize b;
- (id)init {
if ((self = [super init])) {
b = [[ClassB alloc] init];
}
return self;
}
- (void)dealloc {
NSLog(#"ClassA dealloc");
}
#end
int main() {
ClassA *a = [[ClassA alloc] init];
return 0;
}
That should output:
ClassA dealloc
ClassB dealloc
But with NSZombieEnabled set to YES, it outputs:
ClassA dealloc
As far as I can tell, this is a bug. It seems to only happen with iOS (both simulator and device) and does not happen when built and run for Mac OS X. I've filed a radar with Apple.
Edit: It turns out this has already been answered here - Why is object not dealloc'ed when using ARC + NSZombieEnabled . Managed to find it after I found out what the real problem was. It's nothing to do with ARC by the way.
Related
I'm messing around with using objects to launch background threads, however when I call an objects method to call the method that will spawn a background thread, nothing happens. I'm a bit puzzled as to why, and it looks like the -init function isn't even being called. Anyways, here's what I have:
ViewController.h
#import <UIKit/UIKit.h>
#import "Threader.h"
#interface ViewController : UIViewController
#property(nonatomic, strong) Thread* threadedObject;
- (IBAction)StartBackgroundThreadButtonClicked:(id)sender;
#end
ViewController.m
#import "ViewController.h"
#import "Threader.h"
#interface ViewController ()
#end
#implementation ViewController
- (void)viewDidLoad
{
[super viewDidLoad];
// Do any additional setup after loading the view, typically from a nib.
_threadedObject = [[Threader alloc]init];
}
- (void)didReceiveMemoryWarning
{
[super didReceiveMemoryWarning];
// Dispose of any resources that can be recreated.
}
- (IBAction)StartBackgroundThreadButtonClicked:(id)sender {
NSLog(#"Clicked.");
[_threadedObject RunInBackground];
}
#end
Threader.h
#import <Foundation/Foundation.h>
#interface Threader : NSObject
#property(nonatomic) bool IsFinishedRunning;
#property(nonatomic) bool IsThreading;
//Constructor and Destructor
-(id)init;
-(void)dealloc;
-(void)RunInBackground;
-(void)WaitForTenSeconds;
#end
Threader.m
#import "Threader.h"
#implementation Threader
//constructor
-(id)init{
[super init];
if(self != nil)
{
_IsFinishedRunning = NO;
_IsThreading = NO;
}
return self;
}
//destructor
-(void)dealloc{
[super dealloc];
}
//Runs a thread in the background
-(void)RunInBackground{
NSLog(#"Initiating thread...");
[self performSelectorInBackground:#selector(WaitForTenSeconds) withObject:nil];
}
//Waits for 10 seconds, then sets IsFinishedRunning to YES
-(void)WaitForTenSeconds{
NSLog(#"Starting to run in the background.");
_IsThreading = YES;
sleep(10);
_IsFinishedRunning = YES;
NSLog(#"Finished running in the background.");
}
#end
When I run the program, this is my output(I clicked the button a few times)
2013-05-17 15:30:57.267 ThreadedObjects Clicked.
2013-05-17 15:30:59.003 ThreadedObjects Clicked.
2013-05-17 15:30:59.259 ThreadedObjects Clicked.
2013-05-17 15:30:59.443 ThreadedObjects Clicked.
2013-05-17 15:30:59.675 ThreadedObjects Clicked.
I should be getting messages telling me that the Threader object was created, and that it is preparing to launch a background thread, that the thread has been spawned and then after 10 seconds, that the thread is done running.
So, where's my glaring obvious error?
init isn't a constructor, it's for setup after construction. You need the class object to create an instance before you can send init, and, most importantly, you need to assign the results to your variable.
- (void)viewDidLoad
{
[super viewDidLoad];
// Do any additional setup after loading the view, typically from a nib.
threadedObject = [[Threader alloc] init];
}
You can't send alloc to an object that's not a class; instances don't respond to it. The only reason that this isn't crashing is that globals are initialized to 0/NULL/nil, and [nil someMessage] does nothing.
Not assigning the results to your variable is the same as:
int x = 0;
x + 10;
There's no change to x's value.
Additionally, you don't seem to have an ivar there, just a global variable. Ivars need to go into a curly-brace block at the head of the #implementation:
#implementation Threader
{
Threader * threadedObject;
}
// etc...
You never alloc the object.............
Also, this is curious:
#import <UIKit/UIKit.h>
#import "Threader.h"
#interface ViewController : UIViewController
- (IBAction)StartBackgroundThreadButtonClicked:(id)sender;
#end
Threader* threadedObject;
Where exactly did you declare the threadedObject? Like above? Use an iVar
or, better, a property for it!
A couple of reactions:
Show us where your definition and alloc/init of threadedObject.
I'm not sure what business problem you're trying to solve, but this smells like the precursor of some custom NSOperation solution. Operation queues are ideally suited for these sorts of implementations.
I'd be inclined to subclass NSOperation when trying to do something like this. See the custom NSOperation object in the Concurrency Programming Guide.
I'd suggest using camelCase for your method and variable names.
If you say with this, I'd steer you away from the "thread" name, as it might imply that you're doing something with NSThread, which you're not.
I'm developing an app in Objective-C using ARC.
My simplified code looks like this:
ClassA (.m)
MyCustomClass *obj = [[MyCustomClass alloc] initWithValue1:#"abc" value2:1000];
MyViewController *vc = [[MyViewController alloc] initWithObject:obj];
// "vc" will become the first item of a UITabBarController
MyViewController (.h)
- (id)initWithObject:(MyCustomClass *)obj {
...
localReferenceToOjbect = obj;
...
}
- (void)viewWillAppear:(BOOL)animated {
// do something with "localRefernceToObject" <---
}
launching the app will result in a call to a zombie: when the ViewController is shown, the "obj" will be already deallocated and so i can't use it anymore.
my workaround is:
ClassA (.h)
#interface ClassA : UIViewController {
MyCustomClass *obj;
}
ClassA (.m)
obj = [[MyCustomClass alloc] initWithValue1:#"abc" value2:1000];
MyViewController *vc = [[MyViewController alloc] initWithObject:obj];
// "vc" will become the first item of a UITabBarController
is this the right way?! i don't think so: why i've to store an istance of an object that is useless for ClassA?
i can't get an explanation on what's actually happening. could you help me?
You're right in the fact that it is not logical to keep around a reference to obj in ClassA.
But if you need to keep around the reference to obj for MyViewController to use it, retain it in MyViewController, not in ClassA, because that's MyViewController that will use it.
The easiest way to do this is to transform your localReferenceToObject you use in MyViewController into a #property(retain) propertyToObject; (or #property(strong) propertyToObject if you use ARC) and access it in your MyViewController.m with self.propertyToObject (instead of localReferenceToObject, to be sure to call the property's setter and thus really retain the object).
This way, the object will be retained and kept around while your MyViewController instance is still alive.
[EDIT] If you want this property to be private, you can declare it in the class extension so that it is not accessible from other classes, as in the below example. See here in Apple's documentation for more details.
In your MyViewController.h header file
#interface MyViewController : UIViewController
// Here you write the public API in the .h / public header
// If you don't want your property to be visible, don't declare it there
#end
In your MyViewController.m file
#interface MyViewController ()
// This is the private API, only visible inside the MyViewController.m file and not from other classes
// Note the "()" to declare the class extension, as explained in Apple doc
#property(nonatomic, retain) MyCustomClass* referenceToObject; // Note: use strong (which is a synonym of retain) if you use ARC
#end
#implementation MyViewController
#synthesize referenceToObject = _referenceToObject; // not even needed with modern ObjC and latest LLVM compiler
- (id)initWithObject:(MyCustomClass *)obj
{
self = [super init];
if (self) {
...
self.referenceToOjbect = obj;
...
}
return self;
}
- (void)viewWillAppear:(BOOL)animated {
[super viewWillAppear:animated];
// do something with "self.refernceToObject"
}
// This memory management code is only needed if you don't use ARC
-(void)dealloc
{
self.referenceToObject = nil; // release memory
[super dealloc];
}
Personally, as suggested by Apple in some WWDC sessions, I now really rarely use instance variables and prefer the use of properties instead, either public in the .h or private in the .m.
If you use ARC, you can still use an instance variable instead of a property as ARC will retain it for you, but as long as you make sure your instance variable is declared as strong and not weak.
I'm learning Objective-C right now and in order to practice I wrote a simple random maze generator for OS X, which works fine. Next I tried to add some more interaction with buttons, but I'm having trouble with the instance variables as they don't retain the value I assign them. I have come across multiple questions about the same problem, but the solutions to those haven't solved my problem. I also tested if the same problem persists in a simplified version of the program, which it does.
I guess I'm doing something wrong, but I don't know what. Here's what I did:
Created a new project
Added a subclass of NSView called "TestClass"
Added a view with class TestClass in the window in MainMenu.xib
Added an object for TestClass in MainMenu.xib
Added a button to the view and set its tag to 1
Added the following code to TestClass.h and TestClass.m and connected the button to it:
TestClass.h:
#import
#interface TestClass : NSView
{
NSNumber *number;
NSButton *test;
}
#property (nonatomic, retain) NSNumber *number;
#property (assign) IBOutlet NSButton *test;
- (IBAction)testing:(id)sender;
#end
TestClass.m:
#import "TestClass.h"
#implementation TestClass
#synthesize number;
#synthesize test;
- (id)initWithFrame:(NSRect)frame
{
self = [super initWithFrame:frame];
if (self) {
// Initialization code here.
}
return self;
}
- (IBAction)testing:(id)sender
{
self.number = [[NSNumber numberWithLong:[sender tag]] retain];
}
- (void) drawRect:(NSRect)dirtyRect
{
NSLog(#"%#", number);
}
#end
Whenever I press the button, NSLog just returns null several times.
I normally figure out everything by myself (eventually...), but this time it's really driving me insane, so is there anyone who can help me?
Put the NSLog in testing:, or just put a breakpoint there and see what's stored in number.
Note that self.number = [[NSNumber numberWithLong:[sender tag]] retain]; is double-retaining the NSNumber object (which is wrong), but that shouldn't cause any immediate error.
I've read many different things about correct memory management for cocoa/objective-c
For instance ive read that any IBOutlets need to be set to 'nil' but something like an NSArray dosnt?
I would also like to know, is it important to call the super method before or after i release/nil everything
To put this memory issue to bed, can some please reply with the 100% correct way you would create a retained property and release it. If your not 100% sure please dont answer.
Here is what im currently doing but something is obviously wrong as i get the very frustrating EXEC_BAD_ACCESS!?! Almost like im releasing something twice?
header.h
#interface MyViewController : UIViewController {
UILabel *aLabel;
NSArray *aArray;
}
#property (nonatomic, retain) IBOutlet UILabel *aLabel;
#property (nonatomic, retain) NSArray *aArray;
method.m
#implementation MyViewController
#synthesize aLabel, aArray;
- (void)dealloc
{
[aLabel release], aLabel = nil;
[aArray release];
[super dealloc];
}
- (void)viewDidUnload
{
self.aLabel = nil; //Not sure about this bad boy???
[super viewDidUnload];
}
#end
In dealloc you have released the aLabel.Means it is not in memory.Again you are write this line ---aLabel=nil;Remove this line.So that it can't gives the Exec_badaccess.This means eventhough you don't have pointer stilll you are trying to access the pointer.
I have some questions about synthesized properties in Objective-C. The full list follows, but the basic question is this: How does the compiler ensure that the ivars for synthesized properties are properly released, even though my code may or may not include release methods in dealloc?
Note: I decided not to post these as individual questions because they are so closely related and because there are a handful of existing questions that touch on the individual issues without really getting to the heart of the matter.
Somewhat similar questions:
Does property retain need a release?
What's the difference between property and synthesize?
Question on retain attribute with property and synthesize
Setup: Consider a class with a single property:
#interface Person : NSObject
{
NSString * name;
}
#property (nonatomic, retain) name;
#end
Question #1: The very basic case:
#implementation Person
#synthesize name;
#end
With this setup, I assume that name will be automatically released whenever a Person object is released. In my mind, the compiler simply inserts [name release] into the dealloc method as if I had typed it myself. Is that correct?
Question #2: If I choose to write my own dealloc method for this class, and I omit a call to [name release], will that leak?
#implementation Person
#synthesize name;
- (void)dealloc { [super dealloc]; }
#end
Question #3: If I choose to write my own dealloc method for this class, and I include a call to [name release], will that result in a double-release, since #synthesize has already taken care of it for me?
#implementation Person
#synthesize name;
- (void)dealloc { [name release]; [super dealloc]; }
#end
Question #4: If I choose to write my own property accessor for this class, but I do not write my own dealloc method, will name be leaked?
#implementation Person
#dynamic name;
- (void)setName:(NSString *)newName
{
[newName retain];
[name release];
name = newName;
}
#end
Question #5: I have a feeling (based on experience) that none of the above scenarios will result in leaks or double-releases, since the language has been designed to avoid them. That, of course, raises the question of "how?". Is the compiler simply smart enough to keep track of every possible case? What if I were to do the following (note that this is a ludicrous example, just meant to illustrate my point):
void Cleanup(id object) { [object release]; }
#implementation Person
#synthesize name;
- (void)dealloc { Cleanup(name); }
#end
Would that fool the compiler into adding another [name release] to the dealloc method?
Q1:
No. #synthesize does not modify the -dealloc for you. You have to -release the name yourself.
Q2:
Yes it will leak. Same reason as Q1.
Q3:
No it won't double-release. Same reason as Q1.
Q4:
Yes it will leak. Same reason as Q1.
Q5:
No it won't double-release. Same reason as Q1.
You can check this yourself by overriding -retain and -release and -dealloc to report what is going on.
#import <Foundation/Foundation.h>
#interface X : NSObject {}
#end
#implementation X
-(oneway void)release {
NSLog(#"Releasing %p, next count = %d", self, [self retainCount]-1);
[super release];
}
-(id)retain {
NSLog(#"Retaining %p, next count = %d", self, [self retainCount]+1);
return [super retain];
}
-(void)dealloc {
NSLog(#"Dealloc %p", self);
[super dealloc];
}
#end
#interface Y : NSObject {
X* x;
}
#property (nonatomic, retain) X* x;
#end
#implementation Y
#synthesize x;
- (void)dealloc { [x release]; [super dealloc]; }
#end
int main () {
NSAutoreleasePool* pool = [[NSAutoreleasePool alloc] init];
Y* y = [[Y alloc] init];
X* x = [[X alloc] init];
y.x = x;
[y release];
[x release];
[pool drain];
return 0;
}
In Q1, Q2 and Q4, the last -retainCount of x is 1, so there is a leak, and in Q3 and Q5 the last -retainCount is 0 and -dealloc is called, so there is no leak.
From the Objective-C documentation on properties:
dealloc
Declared properties fundamentally take
the place of accessor method
declarations; when you synthesize a
property, the compiler only creates
any absent accessor methods. There is
no direct interaction with the dealloc
method—properties are not
automatically released for you.
Declared properties do, however,
provide a useful way to cross-check
the implementation of your dealloc
method: you can look for all the
property declarations in your header
file and make sure that object
properties not marked assign are
released, and those marked assign are
not released.
This essentially answers all your questions.
The simple and general rule: if you allocate, retain, or copy an object, YOU have to release it.
When you use the retain setter semantic setting in a #synthesize statement, you're asking the compiler to build for you a setter that calls retain on the object. Nothing more, nothing less. And since you are retaining that object (even though it's via magically auto-generated code), you have to release it, and where to release it is in -(void)dealloc.
Something else it's worth knowing - if you have a synthesised property, setting that property to nil (using dot syntax, of course) will release the ivar for you.