Something must be wrong with this code right here:
+ (UIImage*)captureView:(UIView *)theView {
UIGraphicsBeginImageContext(theView.frame.size);
[theView.layer renderInContext:UIGraphicsGetCurrentContext()];
UIImage *newImage = UIGraphicsGetImageFromCurrentImageContext();
UIGraphicsEndImageContext();
return newImage;
}
When I use that, Xcode throws me this error message:
malloc: * error for object
0x103f000: pointer being freed was not
allocated
* set a breakpoint in malloc_error_break to debug
I can't see any memory management errors there. Does anyone else?
I had the same warning. But, it does not occur in 3.1 or above.
Don't see. Set NSZombie enabled in the build to track it down.
It might be related to returning an autoreleased UIImage from a class method which will probably be inside of a temporary autorelease pool. The image might be being destroyed by the draining of that pool. To test, move the method to an instance method and see if the problem goes away.
Related
I am getting memory leak warnings for these two methods. The second one calls the first one and apparently its leaking memory. Any ideas?
static UIColor *subtreeBorderColor(void)
{
return [UIColor colorWithRed:0.0f green:0.5f blue:0.0f alpha:1.0f];
}
- (void) updateSubtreeBorder
{
CALayer *layer = [self layer];
if (layer) {
// If the enclosing TreeGraph has its "showsSubtreeFrames" debug feature enabled,
// configure the backing layer to draw its border programmatically. This is much more efficient
// than allocating a backing store for each SubtreeView's backing layer, only to stroke a simple
// rectangle into that backing store.
PSBaseTreeGraphView *treeGraph = [self enclosingTreeGraph];
if ([treeGraph showsSubtreeFrames]) {
[layer setBorderWidth:subtreeBorderWidth()];
[layer setBorderColor:[subtreeBorderColor() CGColor]];
} else {
[layer setBorderWidth:0.0];
}
}
}
//3: Potential leak of an object
//6: Calling 'subtreeBorderColor'
//1: Entered call from 'updateSubtreeBorder'
//13: Method returns an Objective-C object with a +0 retain count
//12: Reference count incremented. The object now has a +1 retain count
//6: Returning from 'subtreeBorderColor'
//13: Object leaked: allocated object is not referenced later in this execution path and has a retain count of +1
UPDATE 2: I just completely changed the code and deleted temporary files and cleaned the solution and this is what I see - it is finding errors where there isn't even code
Simple. You don't need the call to - retain in the function. That's exactly what the autorelease pattern is invented for. Since you don't create the UIColor object using alloc-init, you don't take ownership of it. No need to superfluously complicate memory management further. :)
Edit: (to prevent future downvotes) now that you edited your question and code so that it no longer erroneously returns a retained object, the previous statement is no longer valid. Yes, Xcode shows this notice about the memory leak where "there isn't even code", and that's strange. Yes, perhaps a compiler bug. Still, a temporary (and in my opinion, perfectly valid) workaround is to simply use a define instead of a function. Let's see what Xcode says if you write this instead:
#define SUBTREE_BORDER_COLOR [UIColor colorWithRed:0.0f green:0.5f blue:0.0f alpha:1.0f]
If you want to be using "retain" the way you are, you need to also "release" the "UIColor" object you returned from your "subtreeBorderColor" method.
Were this my code, I wouldn't do "retain" on that autoreleased object to begin with. Or better than that, simply do my code with ARC enabled.
both pervious answers are right
but, if for any reason you need to retain an object being returned by your method, please follow the rules and rename your method starting with "new" (or alloc or retain or copy), so everybody (and you too) will know that the returned object is retained, so the calling code knows it's responsable to release it later, when needed...
I'm wondering under which circumstances this code breaks in the second assert. In other words, when can -[UIImage CGImage] return nil? The documentation isn't very telling here.
- (void)setImage:(UIImage *)anImage {
assert(anImage);
CGImageRef cgimage = anImage.CGImage;
assert(cgimage);
}
I'm pretty sure, the UIImage is correct since it's fetched from the app bundle. So far I haven't been able to reproduce the case but I do see some user crash reports.
One more possibility that I've come across in the docs:
If the UIImage object was initialized using a CIImage object, the value of the property is NULL.
Another possibility is that you have multiple threads accessing the same UIImage object at the same time; this was happening in my code with the same symptom.
That might explain your sporadic crash reports, too, since the access patterns would depend on timing that changes from run to run.
To the best of my knowledge, if the first assert passes(showing that anImage is not nil) it means that it could not load the image. Check to make sure that the image is being copied into your bundle.
A case where anImage would be non-nil but cgimage would be nil could be contrived as follows:
UIImage* myImage = [[UIImage alloc] initWithCGImage:nil];
As previous answers have indicated there are other ways one could find themselves in such a scenario.
I'm creating an UIImage like this:
UIImage *img = UIGraphicsGetImageFromCurrentImageContext();
Am I responsible for releasing this?
No.
Return Value
An autoreleased image
object containing the contents of the
current bitmap graphics context.
(doc link)
Read the documentation here. As it's written there, it returns an autoreleased object. You don't have to release it. If you want to keep it, you need to retain it somehow.
I have the following method in UIImageManipulation.m:
+(UIImage *)scaleImage:(UIImage *)source toSize:(CGSize)size
{
UIImage *scaledImage = nil;
if (source != nil)
{
UIGraphicsBeginImageContext(size);
[source drawInRect:CGRectMake(0, 0, size.width, size.height)];
scaledImage = UIGraphicsGetImageFromCurrentImageContext();
UIGraphicsEndImageContext();
}
return scaledImage;
}
I am calling it in a different view with:
imageFromFile = [UIImageManipulator scaleImage:imageFromFile toSize:imageView.frame.size];
(imageView is a UIImageView allocated earlier)
This is working great in my code. I resizes the image perfectly, and throws zero errors. I also don't have anything pop up under build -> analyze. But the second I turn on NSZombieEnabled to debug a different EXC_BAD_ACCESS issue, the code breaks. Every single time. I can turn NSZombieEnabled off, code runs great. I turn it on, and boom. Broken. I comment out the call, and it works again. Every single time, it gives me an error in the console: -[UIImage release]: message sent to deallocated instance 0x3b1d600. This error doesn't appear if `NSZombieEnabled is turned off.
Any ideas?
--EDIT--
Ok, This is killing me. I have stuck breakpoints everywhere I can, and I still cannot get a hold of this thing. Here is the full code when I call the scaleImage method:
-(void)setupImageButton
{
UIImage *imageFromFile;
if (object.imageAttribute == nil) {
imageFromFile = [UIImage imageNamed:#"no-image.png"];
} else {
imageFromFile = object.imageAttribute;
}
UIImage *scaledImage = [UIImageManipulator scaleImage:imageFromFile toSize:imageButton.frame.size];
UIImage *roundedImage = [UIImageManipulator makeRoundCornerImage:scaledImage :10 :10 withBorder:YES];
[imageButton setBackgroundImage:roundedImage forState:UIControlStateNormal];
}
The other UIImageManipulator method (makeRoundCornerImage) shouldn't be causing the error, but just in case I'm overlooking something, I threw the entire file up on github here.
It's something about this method though. Has to be. If I comment it out, it works great. If I leave it in, Error. But it doesn't throw errors with NSZombieEnabled turned off ever.
The purpose of NSZombieEnabled is to detect messages that get sent to objects after they've been deallocated. The console error you're seeing is NSZombieEnabled telling you that a release message is being sent to a deallocated instance of UIImage. Usually a bug like this is the result of too many calls to release, or not enough calls to retain.
In this case, your scaleImage:toSize: method returns an autoreleased UIImage. The error message you're getting from NSZombieEnabled suggests that you may be releasing this object after it gets returned. This would explain your bug. When your autorelease pool drains it would try to release an object that's already been deallocated.
You're passing imageFromFile to scaleImage:toSize:, and then reassigning that same variable to the return value. There's nothing wrong with this idiom per se, but does require some extra care to avoid memory bugs like this one. You're overwriting your reference to the original object, so you either have to make sure it's autoreleased before the assignment, or save a separate reference that you can manually release after the assignment. Otherwise your original object will leak.
The error was due to a release going on in the makeRoundedCornerImage method from UIImageManipulator. Still not sure why it wasn't getting picked up without NSZombieEnabled turned on, but that's what it was.
You can find the offending line in the Gist I posted in the original question: Line 74.
Using Instruments, I keep on getting pointed to a memory leak with a UIImage.
I think I'm assigning and releasing the memory correctly. The leaked object in instruments is described as NSConcreteData
Is the following the correct way to assign and release a UIImage?
UIImage* flagimg = [UIImage imageWithData: [NSData dataWithContentsOfURL:url2]];
[flagimg release];
flagimg =nil;
[UIImage imageWithData:] returns an autoreleased object, which should not be released by you again. So this code snipped contains not a memory leak but the opposite, a double free (in the worst case).
Note that Instruments sometimes generates false positives and/or reports memory leaks in the Foundation itself (yep, they make mistakes too :-).
The fastest way to alloc/release an object is to avoid convenience initializers (like imageWithData:) and instead to something like
NSData* data = [[NSData alloc] initWithContentsOfURL:url]];
UIImage* img = [[UIImage alloc] initWithData:data];
[data release];
// use your image
[img release];
This will allocate and release your object right away and not wait until the autorelease pool is cleaned.
But please note too, that a memory leak is generally not memory that is not yet freed, but that is lost and cannot be freed anymore, so an object which will be deallocated by the autorelease pool is not considered a memory leak.
as a general rule you can say
if you create an object an theres a "init","copy" or "retain" in it, you have to release it.
if not, you get an autoreleased object.
thats not always true, but in most cases
both imageWithData and dataWithContentsOfURL return autoreleased objects, so you should have no memory leaks in that code snippet.
Since flagimg is returned autoreleased, your [flagimg release]; call is not needed; you're over-releasing that object.