i am using ARC, my code is as :
-(void)viewAllCustomer:(id)sender
{
if([self.popOver isPopoverVisible])
{
[self.popOver dismissPopoverAnimated:YES];
}
CustomersViewController *allCustomer=[[CustomersViewController alloc]init];
[allCustomer setDelegateAction:self];
[allCustomer.view setFrame:CGRectMake(0, 0, 370, 420)];
UINavigationController *navController=[[UINavigationController alloc]initWithRootViewController:allCustomer];
UIPopoverController *_popOver=[[UIPopoverController alloc]initWithContentViewController:navController];
[_popOver setPassthroughViews:[NSArray arrayWithObject:self]];
[_popOver setPopoverContentSize:CGSizeMake(370, 420)];
UIButton *button=(UIButton *)sender;
// 60.0, 54.0
CGRect buttonFrame=CGRectMake(button.frame.origin.x+25, button.frame.origin.y+35, 10,10);
[_popOver presentPopoverFromRect:buttonFrame inView:self permittedArrowDirections:UIPopoverArrowDirectionUp animated:YES];
self.popOver=_popOver;//popOver is (nonatomic,retain)
}
i am getting memory leak as:
Thanks.
i my self have to give answer of this question, thanks to #abizern.Actually the leak was due to _var._var is just a different name for the instance variable (presumably so you don't accidentally access directly it when you meant to use an accessor).In the code provided to me was accidentally assigning _var to self.var.
i simply made the #property(nonatomic, retain) and use it as self.var in implementation file.No more memory leaks .Also in arc property are auto synthesise, so no more need to explicitly #synthesise removed.
while going through developer apple i found this:
In this example, it’s clear that myString is a local variable and _someString is an instance variable.
In general, you should use accessor methods or dot syntax for property access even if you’re accessing an object’s properties from within its own implementation, in which case you should use self:
- (void)someMethod {
NSString *myString = #"An interesting string";//my bad was that i have taken _myString
self.someString = myString;//again self.someString = _myString //wrong
// or[self setSomeString:myString];
}
Related
I've wrote a class which gets an image from the camera. Its header is as follows:
typedef void(^ImageTakenCallback)(UIImage *image);
#interface ImageGetter : NSObject <UIImagePickerControllerDelegate, UIPopoverControllerDelegate>
{
UIImagePickerController *picker;
ImageTakenCallback completionBlock
}
-(void) requestImageInView:(UIView*)view withCompletionBlock:(void(^)(UIImage*))completion;
#end
As you can see, I'm trying to make something like that in client code:
[[[ImageGetter alloc] init] requestImageInView:_viewController.view withCompletionBlock:^(UIImage *image) {
// do stuff with taken image
}];
Here is how I've implemented ImageGetter:
-(void) requestImageInView:(UIView*)view withCompletionBlock:(ImageTakenCallback)completion
{
completionBlock = [completion copy];
picker = [[UIImagePickerController alloc] init];
picker.sourceType = UIImagePickerControllerSourceTypeCamera;
picker.delegate = self;
[view addSubview:picker.view];
}
- (void)imagePickerController:(UIImagePickerController *)picker_
didFinishPickingImage:(UIImage *)image
editingInfo:(NSDictionary *)editingInfo
{
[picker.view removeFromSuperview];
picker = nil;
completionBlock(image);
}
The problem is since I'm using ARC, the instance of ImageGetter is deallocated instantly after call for -requestImage..., so the weak delegate of picker becomes nil.
Which are common ways to resolve such a issue?
I can see some ways, however, none of them seems to be quite right:
retain ImageGetter from client code, for example, assign it to a strong property. The problems here are: I wont be able to release it by setting this property to nil right after I get image, because this will mean setting retain count of object to 0 while executing the method of this object. Also, I don't want unnecessary properties (well, it is not a big problem, but nevertheless).
disable ARC for ImageGetter and manually retain at start itself and release after sending image to callback.
make static manager ImageGetterManager, which will have method requestImage..., it will create ImageGetter instances, retain them, redirect the requestImage... call, get callbacks from them and release. That seems the most consistent way, but is not it a bit complex for such a little code?
So how can I build such a class?
You can handle that within the ImageGetter class by creating and releasing a "self-reference".
In a class extension in the implementation file, declare a property
#interface ImageGetter ()
#property (strong, nonatomic) id selfRef;
#end
In requestImageInView:, set self.selfRef = self to prevent deallocation.
In the completion method, set self.selfRef = nil.
Remark: Actually you can manage the retain count even with ARC:
CFRetain((__bridge CFTypeRef)(self)); // Increases the retain count to prevent deallocation.
CFRelease((__bridge CFTypeRef)(self)); // Decreases the retain count.
But I am not sure if this is considered "good programming" with ARC or not.
Any feedback is welcome!
If this issue is introduced when switching to ARC, I should just go for option 1, and define it as a strong property.
However the behaviour is a bit different than you described for option 1: Setting the property to nil, does NOT mean the object is instantly released, it will just cause a decrement of the retaincount. ARC will handle that fine, the object will be released as soon as all referenced objects have 'released' it.
You can use the following strategy:
ImageGetter* imgGetter = [[ImageGetter alloc] init];
[imgGetter requestImageInView:_viewController.view withCompletionBlock:^(UIImage *image) {
// do stuff with taken image
[imgGetter releaseCompletionBlock]; // With this line, the completion block will retain automatically imgGetter, which will be released after the release of the completionBlock.
}];
Inside your ImageGetter implementation class, create a method that you can call inside the block like this.
-(void) releaseCompletionBlock
{
completionBlock = nil;
}
I am getting used to using weak and strong references and when to use them and when not and I got to a case like described below (check the comment about the warning)
#interface MPIViewController ()
#property (weak, nonatomic) UIView *subview;
#property (weak, nonatomic) UILabel *label;
#end
#implementation MPIViewController
// ...
// some code here
// ...
- (void)viewDidLoad
{
[super viewDidLoad];
self.subview = [[UIView alloc] init]; // warning here: assigning retained object to weak property
self.label = [[UILabel alloc] init]; // no warnings
[self.view addSubView: self.subview];
[self.view addSubView: self.label];
}
// ...
// some code here
// ...
#end
From description of - (void)addSubview:(UIView *)view:
This method establishes a strong reference to view and sets its next
responder to the receiver, which is its new superview.
This means that this object won't be deallocated after method finishes as it's superview will retain it and hold a strong reference to it and therefore this view will be kept in memory for as long as its superview is there. Am I right here?
I am not sure also if I understand assigning here correctly. Warning says that it will be deallocated straight after the assignment but this sounds wrong as then it wouldn't be possible to assign any variable to a weak pointer as it would get deallocated in the next line of code?
For UILabel same assign works fine, however for UIView it doesn't? Does the compiler treat UIView somehow differently? This really puzzles me how that is even possible.
This code can be fixed easily just by assigning the UIView to a local method variable and then passing it to the setter like this:
UIView *tmpView = [[UIView alloc] init];
self.subview = tmpView;
Variables declared in the method are by default strong so having such a construction removes the warning as the compiler thinks that this variable has a strong reference so weak reference that is then assigned to will be kept as long as the method variable will point to it. BUT! how does that make sense as the tmpView is only a local method variable and will be dumped after method will finish?
To the first question:
Let's have a closer look to it:
self.subview = [[UIView alloc] init];
[UIView alloc] returns an instance with ownership +1. This is assigned to a (non-visible) strong reference, which build the self of -init. -init passes the ownership through. (This is not correct, if -init returns an instance which is not the original receiver, but for your case it is enough details.) So we can think of the return value of -init as an ownership transfer, too.
You assign this instance to a weak variable. In this moment it can be released. (Read: ARC does not promise to do it immediately, IIRC.) the instance variable can be nil before the object is hold by its superview. So this code is dangerous:
self.subview = [[UIView alloc] init];
// _subview can be nil'ed
[self.view addSubView: self.subview]; // add nil
I do not believe that this is your problem, but it can be a problem. – Thinking again about it, it is your problem. Read the edit at the end. –To get rid of it, simply use a strong local variable:
UIView *subview = [[UIView alloc] init]; // defaults to __strong
[self.view addSubView: subview]; // adds an ownership
self.subview = subview;
The second question:
I do not know, why the compiler gives you no warning in the second case. What does happen, if you repair the first case?
At runtime a different handling of both cases is possible, because it is undefined, when the first instance is released. Maybe as a part of optimization a pointer is reused. More detailed:
__strong id completlyHiddenCompilerGeneratedVar;
… = [(completlyHiddenCompilerGeneratedVar=[UIView alloc]) init];
… = [(completlyHiddenCompilerGeneratedVar=[UILabel alloc]) init];
The first instance would be dealloc'ed, when the second instance is created, because it overwrites the internal strong reference.
Again: Repair the first case and tell us, what happens with the second one.
An object need at least one strong pointer to it in order to be kept in memory.
So when you alloc it to a weak pointer that condition is not being met. Make your properties strong if you really need to access these views.
As I understood, I should not be retaining a controller which is a delegate or datasource. I have made a UIPickerView, created in a property accessor as such:
-(UIPickerView *)projectPicker {
if (_projectPicker != nil) {
return _projectPicker;
}
//Create Picker View
UIPickerView *picker = [[UIPickerView alloc] initWithFrame:CGRectMake(0, 185, 0, 0)];
picker.showsSelectionIndicator = YES;
//Create source and delegate
NSString *titleForRow0 = NSLocalizedString(#"<<Make Selection>>", #"projectPicker nil Label 0");
NSArray *titlesForFirstRows = [[NSArray alloc] initWithObjects:titleForRow0, nil];
ProjectPickerDatasource *pickerSource = [[ProjectPickerDatasource alloc] initWithManagedObjectContext:self.managedObjectContext
selectedProject:self.currentProject
andTitlesForFirstRows:titlesForFirstRows];
[titlesForFirstRows release];
picker.delegate = pickerSource;
picker.dataSource = pickerSource;
self.projectPicker = picker;
[pickerSource release];
[picker release];
return _projectPicker;
}
This crashes reporting an attempt to access an unallocated instance of pickerSource.
If I break the pickerSource component out as another property, thereby retaining it within this controller, it works perfectly.
I did not think that was the proper implementation. Doesn't the pickerView retain it's delegate and datasource until it is destroyed?
If the Picker instantiates the datasource it is fine to retain it, it needs to be retained somewhere. Just be sure to release it.
Note, datasources are handled differently that delegates.
Mostly (as for as I know) the delegates are not retained by their classes. They are just assigned like this,
#property(nonatomic, assign) id <TheDelegateClass> delegate;
Its the responsibility of the caller to retain the delegate until the delegates job is over.
The answer for your question is UIPickerView doesn't retain its delegate. It expects you to retain it instead.
in my Mac iPhone simulator (iPhone simulator 4.0) i run my app without problem, but when i change it to another Mac which runs iPhone simulator 4.2 it crushes on a button click somewhere in the app, could the version of the debugger (4.0 and 4.2) be the cause of a potential crash ? thx in advance :))
EDIT
this is the code i have doubt it may cause crash 'cause i use in it a UIPickerView code :
- (void)viewDidLoad {
((UILabel *)[[[[[[switchCommerce subviews] lastObject] subviews] objectAtIndex:2] subviews] objectAtIndex:0]).text = #"oui";
((UILabel *)[[[[[[switchCommerce subviews] lastObject] subviews] objectAtIndex:2] subviews] objectAtIndex:1]).text = #"non";
((UILabel *)[[[[[[switchStationDeLavage subviews] lastObject] subviews] objectAtIndex:2] subviews] objectAtIndex:0]).text = #"oui";
((UILabel *)[[[[[[switchStationDeLavage subviews] lastObject] subviews] objectAtIndex:2] subviews] objectAtIndex:1]).text = #"non";
[rayonDeRechercheSlider setValue:35 animated:YES];
[UIView beginAnimations:nil context:nil];
[UIView setAnimationDuration:1.0];
CGAffineTransform transform=CGAffineTransformMakeTranslation(0,480);
pickerViewTypeCarburant.transform=transform;
pickerViewNomStation.transform=transform;
[UIView commitAnimations];
[super viewDidLoad];
typeCarburantTextField.delegate=self;
nomDeStationTextField.delegate=self;
pickerArrayTypeCarburant=[[NSMutableArray alloc] initWithObjects:#"Sans Plomb 95",#"Gazole",#"Super Gazole",#"GNV",#"Sans Plomb 98",#"SP95-E10",#"E85",nil];
pickerArrayNomStation=[[NSMutableArray alloc] initWithObjects:#"TOTAL",#"SHELL",#"ESSO",#"CARREFOUR",#"BP",#"AGIP",#"CASINO",#"LECLERC",#"AUCHAN",#"ELF",#"AVIA",#"SUPER U",nil];//added
}
One potential problem in your code is that you appear to be assigning to your mutable array properties (pickerArrayTypeCarburant & pickerArrayNomStation) without using the self. notation. What this means is that the arrays are being assigned without using retain semantics (presuming that your #property declaration for the arrays is told to use retain).
The effect of this is that when you try to access this array later in your code you will find that the array has not been retained, and you will likely be receiving some kind of memory warning. Try this instead:
self.pickerArrayTypeCarburant=[[NSMutableArray alloc] initWithObjects:#"Sans Plomb 95",#"Gazole",#"Super Gazole",#"GNV",#"Sans Plomb 98",#"SP95-E10",#"E85",nil];
self.pickerArrayNomStation=[[NSMutableArray alloc] initWithObjects:#"TOTAL",#"SHELL",#"ESSO",#"CARREFOUR",#"BP",#"AGIP",#"CASINO",#"LECLERC",#"AUCHAN",#"ELF",#"AVIA",#"SUPER U",nil];
It's hard to tell if that will solve your problem since I don't know what error is being thrown, however if it is memory related then that could be the culprit.
To be sure, you could run your app in Instruments and see if there are any leaks or allocations where there shouldn't be.
EDIT:
In response to your comment regarding properties, your header file should probably declare your NSMutableArrays like this:
YourClass.h
#interface YourClass {
NSMutableArray *pickerArrayTypeCarburant;
NSMutableArray *pickerArrayNomStation;
}
#property (nonatomic, retain) NSMutableArray *pickerArrayTypeCarburant;
#property (nonatomic, retain) NSMutableArray *pickerArrayNomStation;
// Any method names here...
#end
And at the top of your .m file, just underneath the #implementation line:
#synthesize pickerArrayTypeCarburant, pickerArrayNomStation;
The #synthesize part will automatically create the required accessors and mutators for your properties, based on the information you provide on the lines with #property. In this case, I have defined that the properties should use retain semantics, which means that when you assign a value to your property using self. (i.e. self.pickerArrayNomStation = anArray;) the array you assign to it will automatically be retained by your property. Make sure you include the self. when assigning to a property that uses retain, as this is what tells it to use the generated mutator method, rather than just assigning to the instance variable without retaining.
By the way, make sure that when you generate retained properties in this way that you call [myProperty release]; in the dealloc method, and (assuming your class is a view controller...) self.myProperty = nil in your viewDidUnload method. This ensures that any retained objects are released properly when your views and view controllers are no longer needed.
If you need further information about this stuff, Apple's documentation is your friend. I found their programming guides really helpful when I was starting out. The guide I linked you in my comment under your answer is a good one to start with.
Hope this helps.
EDIT 2
Not sure if this will help, but I have sometimes found that assigning arrays in this way is a little safer... at the bottom of the ViewDidLoad method where you are assigning to your array property, change the code to this:
NSMutableArray *newArrayTypeCarburant = [[NSMutableArray alloc] initWithObjects:#"Sans Plomb 95",#"Gazole",#"Super Gazole",#"GNV",#"Sans Plomb 98",#"SP95-E10",#"E85",nil];
NSMutableArray *newArrayNomStation = [[NSMutableArray alloc] initWithObjects:#"TOTAL",#"SHELL",#"ESSO",#"CARREFOUR",#"BP",#"AGIP",#"CASINO",#"LECLERC",#"AUCHAN",#"ELF",#"AVIA",#"SUPER U",nil];
self.pickerArrayTypeCarburant = newArrayTypeCarburant;
self.pickerArrayNomStation = newArrayNomStation;
[newArrayTypeCarburant release];
[newArrayNomStation release];
I am new to iPhone programming and Objective-C.
I am building a View-based application.
The problem is that none of the UIViewController's dealloc functions are ever called.
I have decided to unload all my retained objects programmaticaly, right before presenting the next UIViewController class.
I have resolved all the leaks detected by Xcode, tested the application with Leaks and Allocations Tools and everything seams OK, but the memory used builds up to around 180 MB and the app crashes.
The self.retainCount before presenting the next UIViewController is 1, the objects owned are released and the pointers are nil, but still the memory builds up.
Can you give me a clue? If needed I will post some code samples. Or can you send me some references to something like Objective-C memory management 101?
This is my interface:
#interface GameScreen : UIViewController
{
IBOutlet UILabel *timeLabel;
IBOutlet UIView *gameView;
IBOutlet UIImageView *gameViewFrame;
IBOutlet UIButton *showOutlineButton;
UIImage *puzzleImage;
UIView *optionsView;
UIView *blockView;
NSTimer *timer;
UIImageView *viewOriginalPicture;
SHKActivityIndicator *activityIndicator;
BOOL originalPictureShown;
BOOL outLineShown;
}
#property (nonatomic, retain) IBOutlet UILabel *timeLabel;
#property (nonatomic, retain) IBOutlet UIView *gameView;
#property (nonatomic, retain) IBOutlet UIImageView *gameViewFrame;
#property (nonatomic, retain) IBOutlet UIButton *showOutlineButton;
#property (nonatomic, retain) UIImage *puzzleImage;
And here is the implementation:
- (id) initWithPuzzleImage: (UIImage *) img
{
if((self = [super init]))
{
puzzleImage = [[UIImage alloc] init];
puzzleImage = img;
}
return self;
}
This is the function called when the user taps the exit button:
- (void) onExit
{
[timer invalidate];
CurrentMinuts = 0;
CurrentSeconds = 0;
//remove piece configurations
[pieceConfigMatrix removeAllObjects];
[pieceFramesMatrix removeAllObjects];
PuzzleViewController *modalView = [[PuzzleViewController alloc] init];
[self unloadObjects];
[self presentModalViewController:modalView animated:YES];
[modalView release];
}
And the unloadObjects function:
- (void) unloadObjects
{
[self resignFirstResponder];
[viewOriginalPicture release];
viewOriginalPicture = nil;
[timeLabel release];
timeLabel = nil;
[gameView release];
gameView = nil;
[originalImage release];
originalImage = nil;
[gameViewFrame release];
gameViewFrame = nil;
[timer release];
[showOutlineButton release];
showOutlineButton = nil;
}
I have a lead of what I do wrong, but I am not sure. Let me explain. I am adding the puzzle pieces to the 'gameView' property. For this, I have a 'SplitImage' object. The following function is called in - (void) viewDidLoad:
- (void) generatePuzzleWithImage:(UIImage *) image
{
SplitImage *splitSystem = [[SplitImage alloc] initWithImage:image andPuzzleSize:gPuzzleSize];
[splitSystem splitImageAndAddToView:self.gameView];
[splitSystem release];
}
Next, initialization function for the SplitImage class and the splitImageAndAddToView function:
- (id) initWithImage: (UIImage *) image andPuzzleSize: (int) pSize
{
if((self = [super init]))
{
UIImage *aux = [[[UIImage alloc] init] autorelease];
pieceCenterSize = [SplitImage puzzlePieceSizeForNumberOfPieces:pSize];
UIImage *outSideBallSample = [UIImage imageNamed:#"sampleHorizontal.jpg"]; //convexity size for puzzle size
outSideBallSample = [outSideBallSample resizedImageWithContentMode:UIViewContentModeScaleAspectFit bounds:CGSizeMake(pieceCenterSize, pieceCenterSize) interpolationQuality:kCGInterpolationHigh];
outSideBallSize = roundf(outSideBallSample.size.height);
puzzleSize = pieceCenterSize * pSize;
pieceNumber = pSize;
if(image.size.height < puzzleSize || image.size.height > puzzleSize || image.size.width < puzzleSize || image.size.width > puzzleSize)
{
aux = [SplitImage resizeImageForPuzzle:image withSize:puzzleSize];
aux = [SplitImage cropImageForPuzzle:aux withSize:puzzleSize];
}
aux = [aux imageWithAlpha];
originalImage = [[UIImage imageWithCGImage:aux.CGImage] retain];
mainImage = aux.CGImage;
imageSize = CGSizeMake(aux.size.width, aux.size.height);
NSLog(#"%#", NSStringFromCGSize(imageSize));
splitImageSize = CGSizeMake(pieceCenterSize + 2*outSideBallSize, pieceCenterSize+2*outSideBallSize);
}
return self;
}
- (void) splitImageAndAddToView: (UIView *) view
{
for (int i = 0; i < pieceNumber; i++)
for(int j = 0; j < pieceNumber; j++)
//some code
UIImage *mask;
mask = [self randomlyRetriveMaskWithPrefix:1 forPieceAtI:i andJ:j];
CGImageRef split = CGImageCreateWithImageInRect(mainImage, cuttingRect);
PuzzlePiece *splitView = [[PuzzlePiece alloc] initWithImage:[UIImage imageWithCGImage:split] andMask:mask centerSize:pieceCenterSize objectMatrixPosition:i*pieceNumber+j outSideBallSize:outSideBallSize pieceType:pieceType pieceFrame:cuttingRect];
[pieceFramesMatrix addObject:[NSValue valueWithCGRect:cuttingRect]];
[splitView setTag:(i+1)*100+j];
[view addSubview:splitView];
CGImageRelease(split);
[splitView release];
}
Thank you,
Andrei
Objective-C memory management 101 is here:
https://developer.apple.com/library/ios/#documentation/Cocoa/Conceptual/MemoryMgmt/MemoryMgmt.html
Ignore the stuff on garbage collection, it isn't available for iOS.
It's not normal to release objects before presenting the next UIViewController.
Assuming you have a NIB, its contents will be loaded the first time that you (or the system) accesses the view member. Your view controller will get a call to loadView, then subsequently to viewDidLoad. If you have any views you want to add programmatically, you can do that in loadView or viewDidLoad, if you want to interrogate objects loaded from the NIB then you can do that in viewDidLoad.
Once loaded, the view will remain in memory unless and until a low memory warning occurs. At that point it'll be released. You'll get viewDidUnload. You should release anything view related that you've still got an owning reference to in there, and set to nil any weak references you may have.
Any attempt to access the view property subsequently will cause the NIB to be reloaded, etc.
So, when presenting a new UIViewController, just present it. If you create objects that are used only for display of that controller then do so on viewDidLoad, and release them on viewDidUnload.
That all being said, the Leaks tool in Instruments should be able to tell you which types of object are leaking and where you first allocated them, so it makes finding leaks really quite easy. The only thing to watch out for is that if one object handles its properties/members entirely correctly but is itself leaked then anything it creates will generally also leak. So when something leaks, check the thing that created it isn't also leaking before tearing your hair out over why you can't find a problem.
First, retainCount is useless.
Activity Monitor is pretty close to just as useless. As well, the behavior in the simulator can be quite different on the memory use front. Better to focus debugging of a problem like this on the device.
Next, this:
The problem is that none of the
UIViewController's dealloc functions
are ever called. I have decided to
unload all my retained objects
programmaticaly, right before
presenting the next UIViewController
class.
Any time you find yourself programmatically working around incorrect behavior, you are just creating more bugs.
Step back from your custom hack and figure out why the dealloc isn't being called. Something somewhere is over-retaining the object. The allocations instrument with retain tracking turned on will show you exactly where all retains and releases are sent to the errant objects.
Leaks likely won't show anything if whatever is retaining the objects is still reachable from a global or the stack (i.e. leaks are objects that can never be used by your program again -- but there are many more ways to explode memory use without it being truly a leak).
You should also "Build and Analyze", then fix any problems it identifies.
Next, if you are seeing memory accretion of repeated operations on the user's part, then Heapshot analysis is extremely effective at figure out exactly what has gone wrong.
Some specific comments:
puzzleImage = [[UIImage alloc] init];
puzzleImage = img;
2 bugs; you are leaking a UIImage and not retaining img. That your app doesn't crash in light of the above code indicates that there is likely an over-retain elsewhere.
retainCount is not a reliable debugging tool.
You should never pay attention to or rely on retainCount. Just because you released it does not mean that some part of the program does not still have a reference to it. retainCount has no value.
Generally as a rule of thumb. If you use 'alloc' you must 'release' at some point.
Unless ofcourse you have put it into an autorelease pool.
Leaks should be able to point you to the objects that are leaking, using that, narrow down to where those objects are added, stored etc.
Post examples of your code on how you instantiate objects and where you release them, you maybe doing something wrong early on.
edit: apologies, i put 'init' not 'alloc' previously, thank you dreamlax, early morning mistake.