I fixed memory leaks of my application using
X-Code->run with performance tool -> leaks
I submitted my application and later I analyzed my code attaching to device like Build & Analyze for device i got many Potential Leaks popped up when i pressed Product then cmnd+shft+B.
What is the difference between the two, was my fixing of leaks based on instruments wrong?
Is it like some leaks pointed by analyzer may actually cause leaks which are not shown/caught by Performance tool?
When you run the leaks performance tool it will let you know WHEN a leak actually happened. Build & Analyze warns you of potential leaks that COULD happen while your program is running.
Your fixing leaks based on instruments was not wrong, but you should also carefully look into the leaks build & analyze tells you, as they could potentially leak when the program is actually running.
Related
Memory testing. What are the Possible automations?
I would like to do UI automation tests and look into memory testing using xcode9 instruments. This is something that is currently hurting our product. In the app there are places where the application leaks memory causing crashes in very random locations which makes reproducible steps difficult.
How can I create a subset of test scripts and capture where the leaks are?
I can check memory allocations and leaks manually using instruments as below -
I am running the Instruments Tool (Leaks) and am receiving memory leaks in the QuartzCore library and don't know exactly where in my code this is occurring. Usually I'm able to pin point the line where the leak is occurring, however the instrument tool isn't giving me anywhere to view this type of information.
What would be some other things I could look at in terms of diagnosing such a leak?
First, try running this on the device. Sometimes the simulator will report leaks that do not exist on the device.
Secondly, open up the stack trace (right sidebar) and see what code of yours might be involved higher up in triggering this call, then you can think from there why that code might be leaking.
One additional bit of advice. Instead of playing with leaks there, switch over to ObjectAlloc and use the Heapshot feature - if you know about where the leak is, use the heapshot to set a base memory measurement and every time you hit the "heapshot" button after that you'll see a kind of memory "diff" against that baseline you set. Solving any over-retained problems might also fix your leak.
If you’re only leaking 16 bytes at a time, it’s really not likely to become an issue in your app. And if the leak is occurring in a system framework, it probably isn’t your fault.
I'm in big trouble now, my iPhone application keep terminating again and again due to memory leaks and I am unable to judge that where are those leaks. Tell me what step can I take in order to resolve this problem.
Thanks
You can use Instruments to see where potential leaks are.
Here is a good tutorial. http://mobileorchard.com/find-iphone-memory-leaks-a-leaks-tool-tutorial/
I think you're confusing terminology here. A memory leak is when you don't release an object after you're done with it.
A leak won't directly cause a crash. Leaks can indirectly cause crashes if you run out of memory as a result of not releasing lots of objects. However, if your crashes are happening in the simulator as well this is almost certainly not the case (the simulator having far more available memory than the device). As Daniel says, you can use the instruments tool to find out what's leaking.
Another good method is to use the XCode static analyzer - you can have it analyze your code and detect most common leaks.
Now, if your app is crashing and it's not because of a memory leak (you'll be able to tell this because you'll have memory warnings outputting to the console) then chances are your problem isn't a leak. Perhaps it's a bad access (you're over releasing), in which case your instruments leaks tool isn't going to help you.
If you need to find out leaks and source of crash. you can try these
try to find as many leaks as possible from Instruments and fix
set NSZombieEnabled for your executable parameters and debug application crash
change all your autorelease objects to use alloc init as much as possible.
--
worst resort is if it keeps crashing even after trying all the above three. you write memory intensive module of your code in a thread and clean up that thread. I've noticed usually when threading is done the memory footprints are much cleaner. This is just my opinion, but the above 3 you should do.
You could also Build + Analyze your application in XCode itself (Cmd+Shft+A or Product > Analyze). It'll show you the more obvious leaks.
I'm new to memory management and have been playing around with Instruments in Leaks mode. This is my latest output and I was wondering if I could get some feedback from the SO community. It seems as if my total leak amount is quite high, even though the individual leaks are not that big (I think). Should I be concerned? Should I be looking to get rid of all of these leaks?
N.B. The app runs on the iPhone and doesn't use any network.
The screen you are looking at is not the Leaks. It is the memory allocations of your app.
I have an app that often crashes on the device (iPad), but not on the simulator, so any simulator debug tactics (MallocStackLogging for example) are not an option. What I usually get in the console is this:
Received memory warning. Level=1
Received memory warning. Level=2
Program received signal: “0”.
Data Formatters temporarily unavailable, will re-try after a 'continue'. (Unknown error loading shared library "/Developer/usr/lib/libXcodeDebuggerSupport.dylib")
My question is, at this point, is there something I can do to find out exactly what is causing the crash? Obviously it's a memory issue, but I'm having a hard time finding the cause. Is it a leak? Too much allocation? Is there anything besides "Run with Performance Tool > Leaks" that I can do to track down the problem?
Another good tool is the Static Analyzer. Just click Build and Analyze in the Build menu and it will show you somewhere between many and most of your memory leaks.
Check out the Apple Developer Document for more explanation on how to read the results.
Use Instruments to see where all your memory is going.
I'd start with Run with Performance Tool -> Allocations.
Also, I find Leaks to be pretty conservative. I haven't seen a single false-positive from Leaks, but I've found plenty of leaks that Leaks didn't detect.