I have developed application and all is well. As well, I also keep memory foot print very low.No leaks show during application run. I tested application more than two hour and there is no crashing report. But when i checked application on instruments at that time it's show me following leaks.I have checked my app but there is no such leaking object. "Even I used app continue 12 hour and it didn't crash or stop".
//Here the screen shot of instruments.
///>>>>>>Here, I uploaded latest screenshot of leaks.It may help somebody to understand where the leak is.
// I think it's library file leaks(CoreFoundation)...Please Suggest What to do..
Please help me, This is really screw me up.
Thanks.
Not all of the 'memory leaks', are actual leaks. And some of the reported issues may be caused by Apple libraries themselves. Typically all the singletons, static variables, and some c level variables are 'leaked', but only once and are not considered a threat to memory.
Foundation classes such as NSString, NSArray, etc. are optimized to handle heavy workload. And some objects may be kept in the memory to be reused later. Such as #"".
So unless the issue is accumulating over time, just go for it, submit your app as it is. You still can fix it later, if necessary.
Hey analyze you code using "command+shift+b" and fix all leaks whatever coming after analyzing, submit it to app store. I don't think we can fix all leaks shown by instrument, so better to go with command+shift+b. I think we should use instrument only when getting memory warning and crashes due to insufficient memory.
Related
There are some memory leaks found out when i "profile" my app with Instruments.
Some of the leaks are obvious and easy to fix, but some are not. Some of the leak log showed in Instruments are really bothering me. For example:
I even can't tell which line of my code called these "strangers" behind the scene. How can i fix these leaks? Is it a leak from my code? From the framework? Or just a false report?
Then my questions are:
A: Is it possible to fix all memory leak bugs? Some of them are really hard to deal with. And you even can't tell is it a bug from your code or from the frame work.
B: Is it necessary to fix all memory leaks? Couple of bytes leak might affect nothing. And the effort you put on to fix it may cost a lot more than you can get.
A: Is it possible to fix all memory leak bugs? Some of them are really
hard to deal with. And you even can't tell is it a bug from your code
or from the frame work.
Yes it is possible, but please note some times the result you get from profiling dont pont you necessarily to a leak, sometimes they are objects that are not yet been auto released and sometimes they are not yours.
B: Is it necessary to fix all memory leaks? Couple of bytes leak might
affect nothing. And the effort you put on to fix it may cost a lot
more than you can get.
If you mean for your application to not be rejected, then no thats not necessary, dont overwork and stress yourself on some bytes that you cant seem to find, dont go and search for a couple of bytes that has been lost here and there, start looking for leaks only when you notice that your application is really leaking.
Yes it's possible and yes you should.
Leaking ins't good in the long run, especially if you app runs in background.
If the leak is in a third party library, tell the maker to fix it. Or if you have the code fix it your self.
Leaking in you own code can easily be fixed, so do it.
If your application is running for long times(consider as a some server) then it keeps on making that 2 bytes of leak at a frequent of time. At some point of time your heap will be full of infinite leaks. This may leads to malloc failure in your application. So fixing memory leak is more important for application which is running for long time. And also there will be possible to fix all the memory leaks.
If an application is running for short time means, once the application exist all the resources will be freed by the operating system, at that time leaked memory also will be freed.
Recently my iphone project comes to the end, but suffer some random crash during app running, and the call stack is always located in COCOA library, tough issue, don't know how to deal with it, for some cases I even suspect that is it apple's defect?
My questions.
For those random crash issue with few reproduce rate, how do you guys handle it? Any method to help to increase reproducible rate?
How to fix these crashes located in COCOA library? How to find more clues?
Any idea or discussion will be appreciated, thanks in advance.
If the app crashes in the COCOA code it does not mean that COCOA code is wrong - much more likely you fed some invalid data to it (for example nil where it does not supposed to be). If it's happening randomly there might be some multithreading concurrency behind or some of your objects become (auto)released too early, etc. You have to carefully analyze your code which operates with the COCOA classes where your crash happens, or try memory management debugging as suggested by other answerers.
Generally, I don't start thinking that is COCOA the problem. It happens, but most cases the fault is ours.
When this kind of crashes happens the first thing to do is to run the static Analyzer, sometimes it's just a retain/release problem.
If you're using ARC, skip this part and start creating an Exception Breakpoint (search 'To add an exception breakpoint...' in linked guide). The exception breakpoint helps to have a more detailed crash log when an exception is thrown.
The third step is using Instruments, looking for waster memory, leaks and any other form of memory drain. How to use Instruments is deeply explained in a couple of WWDC videos.
Enable NSZombie flag.
project(On Top LeftCorner of xcode)>Diagnostics>enable zombie objects
It will lte u know where ur code is crashing ..find it fix it
I have been using instruments to check for leaks and other memory issues in my program. Though the leaks found by instruments are extremely small and don't matter, I have found that the physical memory free keeps going down while I use the program.
I use memory monitor to determine how much memory my app is using up and allocations to determine where this is mainly happening. I always make sure to release every time I alloc or retain, and seeing how there are barely any leaks, I'm assuming that my memory management is fine.
Does anyone know what I can do to fix this issue or reccomend a way to get to the bottom of it?
Even tho you release objects you dont need, that doesn't matter. You are probably allocating too much things and keeping them for some reason. You can try to check this out:
http://macdevelopertips.com/objective-c/objective-c-memory-management.html
http://akosma.com/2009/01/28/10-iphone-memory-management-tips/
I would advise you to check what you alloc and what you keep for the life of the application and see if you can make the same thing but without using so much memory.
Edit: I have to agree with Mark and Kongress, every leak matters for the sake of your app's life.
I have a navigation based template, when I run my application using Instruments, the very first memory leak comes under:
Leak Object: Malloc 128 bytes
Responsible Library: CoreGraphics
Responsible Frame: open_handle_to_dylib_path
I don't know where this leak is coming from and how remove this.
If it's a default leak, then I think I don't need to worry about it. But if it's not then I have to find a way to remove the leak.
Expanding on deanWombourne perfectly correct answer a bit..
The Leaks Instrument shows you memory that isn't going to be free'd in the normal course of the app (because there aren't any references to it). This in itself is no biggie, it will be free'd when the app exits. A lot of the framework code will allocate and leave these very small chunks of memory allocated. I have no idea if they are mistakes or essential to how the app runs. Whatever, we must accept that they are completely normal.
Leaks will identify these chunks of memory as 'Leaks' and that sounds bad, but this is not really the 'Leaks' that the instrument is there to help you identify.
The 'real' leaks are in the code that can be run many times and which allocate some memory that is never freed, so over time will consume more and more memory until all memory is used and your app will crash.
So if you have an app that no matter how long you use it for or no matter how you use it, it 'leaks' 128 bytes in an apple framework you generally don't have to worry.
However, if you have an app that say, every time you click a button it allocates a new string which is never released - no matter how many bytes the string is - if the user pressed the button enough times this would consume all the memory available to app and eventually crash it. This is the kind of leak you need to watch out for.
The leaks instrument realistically can't tell the difference between the two kinds, but you need to be able to. You might want a kind of singleton object, for example, that there is only ever one instance of, and that needs to exist for the entire lifetime of your app. You create the object on app startup and realistically you never need to free this object, it can be killed when the app exits. Leaks will flag it as a leak, and some other developers that you work with who assume that this means you don't know what you are doing will run to your boss like a little child and say "He's writing really leaky code, and that's reeeeally bad". And your boss, who isn't a programmer will take him seriously because it does sound bad and anyway he scraped a 2.2 in CS from a reputable University so he must know what he's talking about. When really it is completely reasonable and exactly what you meant to do.
So, use the Leaks instrument to find bugs in your code that will ruin your app. Don't worry about every byte found 'Leaking' in an Apple framework.
If it's a one off 128 byte leak then don't worry about it at all, there are better ways to spend your time than thinking about this :)
Another memory question on iPhone - When running the leaks application I see a number of leaks get identified, but are caused by NSFoundation or similar, rather than my application code. Where my application name is mentioned, I have obviously resolved the leak.
I assume I can ignore these and that my app will be approved, or am I reading the data incorrectly?
Also - does the application have to have zero memory leaks before it is approved?
Cheers
Memory leaks will not cause your application to be rejected unless they contribute to general instability - e.g. a leak while moving forwards/backwards between views will eventually cause your app to crash.
Thats said, there are few actual leaks in the SDK libraries so be sure to check the leak are not actually a result of something your code is doing.
Any leaks that apple finds in testing of its own stuff will get fixed (and Apple does definitely test for leaks). The frameworks are not completely leak free, but it's dangerous to assume that a problem is in the frameworks. Here are a couple things to keep in mind:
(1) If you leak an object, the entire tree of objects hanging off it will also be reported as leaks. Suppose an object of class NSPrivateWhosit that you've never heard is leaked. Does that necessarily make it Apple's problem? No, it might be something used by an instance of NSPublicClass that you leaked.
(2) If an object is allocated in Foundation and passed to you, and you retain it, then you can leak it. The backtrace of the allocation doesn't matter. What matters is the backtrace of the unbalanced retain.
Your application will get approved even with memory leaks (at least my buggy application did get approved).