I recently met a problem using blocks with Facebook's app switching. I needed to call a block after the Facebook login.
First my block was destroyed when the app switched back ('cause it was on the stack), so I decided to retain it. But that didn't work, and I messed with that problem :/. I found a solution on that blog and also here.
My question is simply : why copy works and retain does not ?
Because when you create a block there is nothing to retain, since it doesn't exist in the heap until you copy it there with Block_copy. This is covered in the WWDC lectures about blocks.
More info: http://www.friday.com/bbum/2009/08/29/blocks-tips-tricks/
See my recent answer to another similar question:
By default blocks are created on the stack. Meaning they only exist in the scope they have been created in.
[...]
Read Stack and Heap Objects in Objective-C by Mike Ash for more info on stack vs. heap.
Related
I remember from watching CS193P from Stanford University on YouTube (yes, I'm a smart bunz)... that there's this thing called a memory leak or "retain cycle" -- something really bad -- that can happen when you do things like this:
referencing self. within a completion block
referencing self. within a timer callback
referencing self. within a SyncQueue.sync() method
referencing self. within a DispatchQueue.main.async() method
The solution generally seems to be to use the "weak self" reference instead.
I have 104 of these asynchronous self. references in my ViewController which is why I am a little worried.
HOWEVER... this app is a single-page app... and ALL these self. references are pointing to this main ViewController (or one of its permanent sub-views) which is always there, never dismissed, and never "popped from the stack."
My app seems to work fine... and I don't see the total memory usage going haywire or anything... So does that mean I can leave my (ViewController) code as-is in this regard?
Thanks for help!
Here are two situations where you may regret not fixing your code:
If the device runs low on memory when your app is in the background, there are aspects of your view controller and its views that can be deleted. See this (admittedly old, but still interesting) article. This could easily affect your app more significantly in a future iOS version, or maybe even now depending on what your code is doing.
Jump 6 months ahead, where you or someone else on your team is borrowing some of your code for another app. You (or they) will likely get burned. Best to just fix the code now. The fixes shouldn't cause a major refactor, but if you find one that does, you could always insert a big warning comment at that line instead.
I am debugging an iPhone app that was written by someone else, it doesn't use arc. I have tried using arc but they have a lot of old code that uses some c style void pointers, so the program crashes when I do.
I have given up on that idea as a lost cause. The problem is that the allocations / leak tools don't show a memory leak, but the Activity monitor shows memory being leaked every time the user swipes to change a page. (about 1.5 Meg each swipe) Needless to say the program crashes.
Being a c++ programmer myself, with some objective c experience I don't understand all the ins and outs of where the memory is being held onto. Can someone give me some pointers on how to track this one down.
Thanks
I highly recommend spending a day and reading the Objective-C Programming Guide in depth (the retain/release/auto release sections) until it clicks. Also properties which are almost for sure in play here.
Specifically, some memory has been retained by either one too many retains, by a property setter doing that as a side effect, or a view holding onto UI elements (getting hidden but not removed from its super view).
In the Instruments Allocations view, you can see the types of objects that are not getting released - this should help track it down.
Another trick is to put log statements in dealloc methods, to see what large objects are NOT getting released (no log statements in the console).
Your last option is to either post your code and ask for help here, or hire someone to get you past this or to ARCify the code.
EDIT: I had an idea over the weekend on how one might track arbitrary objects - to get an indication of whether they were getting released or not, so I created an Object Tracker project. Using the Tracker class, you can mark objects for tracking, and when the object gets dealloced you'll see a log message in Xcode. Also, you can query the class object to see what objects are still living.
It works by using objc_setAssociatedObject() to attache itself to the tracked object, then logs itself when that object is dealloced (and thus releases the tracker object.
So, you can try a few objects in your project - views, scrollViews, images, arrays, etc, and see if you can at least find the object that isn't getting dealloced when it should be.
Hope this helps.
Recently I was facing an issue where I was navigating from a screen A to screen B. when I was coming back from screen B to screen A, the Live Bytes in the application were not returning to the initial value. After further investigation I found out that I was retaining some global objects in some methods which were called more than once. So I had to fix the calling mechanism of the method.
I fixed the issue, but I was thinking about one alternate solution. What if I simply used a for loop in dealloc which runs depending on the value of retain count. I think it is not advisable to use such approach, but what is the exact problem in this approach if I am sure that the objects are not accessed from anywhere outside the file.
Thanks in advance.
What if I simply used a for loop in dealloc which runs depending on the value of retain count.
I wouldn't be surprised if Xcode detects code like that and energizes the aluminum case of your MacBook Pro with several amps.
I think it is not advisable to use such approach, but what is the
exact problem in this approach if I am sure that the objects are not
accessed from anywhere outside the file.
You're right -- not advisable. There are at least two problems:
It completely breaks the memory management paradigm of Objective-C. You really can't be sure that no other object has retained one of your objects. Just one example: you don't know in your -dealloc method whether any of the objects to which your ivars refer might have been autoreleased.
It's the wrong fix. Doing what you propose doesn't fix bugs in your code, it only covers them up. Your objects should correctly manage the objects that they use, and not worry about what other objects may or may not have retained. If you follow that simple formula, you don't have to worry about whether objects are accessed from "outside the file" or not -- everything just works.
Not only should you not use -retainCount to run the number of retains down to 0, you shouldn't look at -retainCount at all.
Retain count is not for you to count on. There are some internal implementations which increase/decrease the retain count without you know it so using it is not advisable.
You should use the xcode instruments for finding memory leaks which will lead you to places in your code where objects are retained and not released.
or you can just enable ARC and let it manage the memory for you.
Dear fellow iOS developers,
I'm still developing without ARC (switching coming soon) and after an interesting discussion with a iOS beginner, I've presented my way to initialize a retain property (let's call it property), that I inherited from Apple docs at their pre-ARC era:
NSObject *tmpProperty = [[NSObject alloc] init];
self.property = tmpProperty;
[tmpProperty release];
I see a great benefit with this: it makes memory management clear.
There's also a great drawback: it takes 3 lines, for something very basic. So we assumed: why not the following solution?
self.property = [[[NSObject alloc] init] autorelease];
It's less clear about memory management but much more compact (and it propably make the ARC-migration easier to achieve).
What are (were?) you using yourself? Do you think one of these is a clearly better solution than the other?
Using autorelease is never a great option, as you have no control over the lifetime of the object you are initializing, so it may be the case that
In a ViewController you have initialized some object e.g. property, and you are swtiching to some other views, and if you want to come back to the older ViewController and access the object, it might be released by the iOS, and your app might crash.
I think switching to ARC at the earliest would be your best option. I think ARC should be used by every developer, almost all the devices are being provided by the iOS5 update, so there might be least chances of supporting older devices.
Hope this solves your doubt
I am using the first where ever I can, because it uses less memory. In the second case the object you have allocated is released when the run loop finishes. This can be important when you have this code in a for loop or in a table view cell. In some circumstances this can make the difference between 'memory warning' and 'everything is fine'.
By the way: Switch to ARC.
A little of both. I don't think it something that a convention should say "One or the other".
The one-liner works well when you need just one line. Ownership requires no additional reading.
When you need further initialization (e.g. before you set self.property) or in some cases want to minimize possibility of an object being added to an autorelease pool or its destruction more predictable, then you may favor the second.
However, I wouldn't fret about it much if you're about to move over to ARC -- a lot will change then and you may wind up going through extra work for no gain following the migration.
I have been having a bit of a bug while testing on iOS 6 with my current iOS 5 app.
We have experienced a lock up on a method return for an innocuous method that internally used blocks, but not as properties. The issue is that calling the method works, so does every line of code within the method (including the block utilizing code)
I tried using [block copy] before calling the block, but there was absolutely no change.
turns out the function definition of my code was declared in an internal interface and did not have a return type.
Here are some graphics to illustrate this issue.
The Initial Error
The Stack Track
The Method in Question (isolated from self to determine the issue exact location)
The Function Implementation (this is what is called, and returned)
The Definition in the Private Interface
I decided to look at the function call, and noticed it returning (id) rather than void
And Finally the only code change that alleviated this bug.
Explanation
This bug reared its ugly head when my client called me saying our app does not run on ios 6
I was forced to download iOS 6 and Xcode 4.5 for testing this out.
I did indeed crash every time the app was run.
After hunting down this bug on stack overflow among other sites linked to by Google, I tried the block issue that some others are experiencing. And did a copy wherever I could to try to alleviate the issue of retained object falling off the stack.
I was not using block properties so I just called copy on the blocks themselves.
This did not help.
Finally with another developer going over it with me. I was stepping back and looking at it from another angle, and decided to try to determine what the heck was being retained.
It turned out the result of the function was being retained. And the only way I figured that out was to look at the value that auto complete showed me as the return type.
I knew the return type to be void, however it was telling me that the return type was id and that is what sparked the investigation into the method definition.
I hope this helps others that have this issue as I spent about 2 hours hunting it down and it turned out to be a semantic issue between a result type that should never have existed.