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 -
Related
I've recently integrated the PHPickerViewController per Apple's recommendation for accessing photos within your app. However, testing for memory leaks, I've noticed the picker is producing many memory leaks. I'm running the PHPickerDemo and see the following leaks while profiling:
Image from Instruments Memory Leaks
Any thoughts on how to solve this or is this something we have to wait for Apple to fix?
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.
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'm doing some performance testing in Instruments on the device for an iPhone application that is in development.
I'm seeing that the two largest chunks of memory that are been allocated aren't through any of my custom methods (to my knowledge).
Screenshot 1: http://i.stack.imgur.com/yFFux.png
The background to the application is that it is an application, which uses CoreData to consume a web service and store/display the data. Linked images are then downloaded (async), resized to a smaller size within the app and the new image is then displayed. I originally thought that the images were the problem but testing the app in offline mode without the data or images been downloaded and the large Malloc of 4.5mb still appears.
I'm struggling to identify the source of the memory footprint and ultimately try to reduce/remove it through an AutoRelease pool or another means.
It's really hard to diagnose memory issues from a few screenshots. Your best bet is to learn a bit more about instruments and memory profiling so you can determine for yourself what the problem is. I highly recommend watching the WWDC 2010 session 310 - Advanced Memory Analysis with Instruments. It really helped me to learn where the problems in my app were.
When I run my iPhone app with "Leaks" (which has a section for Object Alloc), my app seems to be fine for memory allocation. However, when I run it with just the ObjectAlloc tool, the memory increases steadily as the app runs its main timer. (It is a timer based app). I'm not sure what to trust. I was just wondering if there are any issues with the ObjectAlloc tool that might pertain to me. Maybe something related to NSTImer? I'm running this on the device (not the simulator). Thanks.
Yes -- trust the tools. They are really quite accurate these days.
Leaks means an object or allocation for which the address of said object/allocation isn't stored anywhere else in your app. The memory is no longer accessible.
However, eliminating all leaks does not mean your app cannot grow without bound.
Unbounded growth can happen for a number of reasons. You might have a cache that keeps adding entries without pruning the least recently used entries. Or maybe a transaction log that is never truncated or flushed to the filesystem. Or you might keep loading new images into your application without throwing out the old.
Once you have eliminated all leaks, look at the output of ObjectAlloc and figure out where all that memory allocation is coming from. In particular, you'll want to figure out what your app is doing to trigger the allocations. The system frameworks won't spuriously cause continual growth without your application directly or indirectly asking for the resources to be consumed.