In the Memory Leaks tool in XCode 7 what do those crosses in the timeline represent (and the grey shape with the minus)? I could not find this in the documentation and they appear regularly on the timeline.
I get a long lists of leaked object (this is a big project developed in the last years). Should this list be always empty, or it's normal to get some leaks in a running app, or does this implies that it's bad written code?
I can answer the first question. The Leaks instrument checks for memory leaks every 10 seconds initially. If the Leaks instrument finds new leaks since the last check, it shows a red symbol with an X in it (the red crosses). The gray symbol with a minus sign means the Leaks instrument has found memory leaks, but no new leaks since the last check.
The goal is to get the Leaks instrument to show a green symbol with a checkmark. That means no leaks were found.
Summary
Green: no leaks
Gray: no new leaks
Red: new leaks
Just to have an idea: should this list be always empty, or it's normal
to get some leaks in a running app, or does this implies that it's bad
written code
No, it is not a normal thing and surely this is an ugly code with these many leaks.
If you are dealing with this application now, you should try to reduce to ZERO leaks, or minimise to an acceptable state(here I mean if some leaks are from some 3rd party libraries).
Even I worked on a project that is in production from a decade with 2K classes, that doesn't have any leaks, but ever release we find some and remove it, otherwise the client will not accept the code.
Related
I'm working on a Mac app. Initially monitoring Xcode's memory report while I ran my app showed showed the memory was just ramping up crazy. I used Instruments and profiled my app for allocations and leaks. Turned out there wasn't much leaked memory as you would expect due to strong reference cycles etc. However there was a lot of abandoned memory. By following the stack trace that lead to my code I have fixed by 70% using autorelease pools etc. Still the remaining 30% of abandoned memory seems to point system calls.
Now I have two questions based on that I have two questions
1) I want to fix the remaining 30%. How can I get rid of abandoned memory? I have already used Instruments and know exactly where those system calls are spawned but still dont know what to do to have that memory be cleaned up. (using ARC no manual retain/ release and autorelease doesn't seem to make a diff.)
2) After I know whatever my application was doing has completed and there is no need for any memory to be there (just like the application first started) I want to get rid of all memory that my app has used up. This I plan to use as a brute force approach to clean up all memory just like the system would if the user closes the app or turns off the system.
Basically if I know where my apps memory is in the file system I'll just programmatically call purge command on that or something similar. Because at this point I'm 100% sure nothing needs to be in memory for the app except for the first screen that you would expect the first time you launch the app.
I read this, this, this and this but they weren't helpful.
What does "Memory" usage chart/graph exactly represents in XCode 5 Debug navigator window?
I have an iOS app project with ARC disabled and no-storyboard/xib (i.e. old style). All memory management done manually using retain/release/autorelease.
When I debug the project in XCode 5, the memory pie-chart / graph show gradually increasing memory usage as the app runs, exceeds 1 GB memory footprints within half hour.
Roughly, it keeps increasing by 0.1 to 0.3 MB per 2 to 3 second with very rare memory dips/decrease (of magnitude < 0.1 MB per 30 seconds).
Is this a concern (memory leak) with respect to memory management? I did memory analysis (using Allocations/Memory Leak through Instruments on XCode 4.6) but didn't find any leaks.
Found answer myself. Unfortunately I had NSZombieEnabled (Zombie object) for debug mode - see below - (menu Product > Scheme > Edit Scheme)
Typically NSZombieEnabled tool keeps even the released objects in memory to help developer find over released objects. Refer this link - What is NSZombie?
After I unchecked "Enable Zombie Objects" option, the memory usage stabilized to about 10 mb (not always increasing) even after half hour app usage - see below -
BOTTOM LINE - Ensure to clear "Enable Zombie Objects" when you want to analyze memory usage.
It simply measures the memory your app uses. So if it is increasing it must be a memory leak.
When using the leak analysis tools, I would use it as a guideline. It may help you find leaks but with all automated tools it may not find it all. As certain pieces of code (Especially the more dynamic pieces) may be hard to predict what they do memory wise for an automated tool.
I am seeing an issue where memory (heap) grows indefinitely on heavy processing but when running the exact same binary without Xcode; memory usage is fine. Remember to test outside of Xcode -- no idea what the cause is. NSZombies and all other debug options are off.
I recently I came across an error that I cannot understand. The game I'm developing using Cocos2D just freezes at a certain random point -- it gets a SIGSTOP -- and I cannot find the reason. What tool can I use (and how do I use it) to find out where the error occurs and what's causing it?
Jeremy's suggestion to stop in the debugger is a good one.
There's a really quick way to investigate a freeze (or any performance issue), especially when it's not easy to reproduce. You have to have a terminal handy (so you'll need to be running in the iOS simulator or on Mac OS X, not on an iOS device).
When the hang occurs pop over to a terminal and run:
sample YourProgramName
(If there are spaces in your program name wrap that in quotes like sample "My Awesome Game".) The output of sample is a log showing where your program is spending time, and if your program is actually hung, it will be pretty obvious which functions are stuck.
I disagree with Aaron Golden's answer above as running on a device is extremely useful in order to have a real-case scenario of where the app freezes. The simulator has more memory and does not reproduce the hardware of the device in an accurate way (for example, the frame rate is in certain cases lower).
"Obviously", you need to connect your device (with a developer profile) on Xcode and look at the console terminal to look for traces that user #AaronGolden suggested.
If those are not enough you might want to enable a general exception breakpoint in Xcode to capture more of the stacktrace messages.
When I started learning Cocos2D my app often frooze. This is a list of common causes:
I wasn't using sprite sheets and hence the frame rate was dropping drammatically
I was using too much memory (too many high-definition sprites. Have a look at TexturePacker and use pvr.ccz or pvr.gz format; it cuts memory allocation in half)
Use instruments to profile your app for memory warnings (for example, look at allocation instruments and look for memory warnings).
I followed this video tutorial for detecting memory leaks using Instruments with Xcode 4.3.2.
As you can see from the video, the creator gets a lot of useful feedback on the type of object that was leaked etc.
When I run instruments, I detect a few memory leaks but don't get much useful feedback on them:
What does it mean "Root Leaks"? Why is there no more useful information like in the screen above?
Is this something I can fix?
I'm using ARC within my app - does that effect Instruments finding memory leaks in any way?
A root leak can be one of two things. It can be a single memory leak, or it can be the start of a leak cycle. A leak cycle occurs when you lose a reference to a group of objects. A memory leak leaks one object while a leak cycle leaks a group of objects.
Your code may not have any leak cycles, which would explain why your Cycles and Roots section shows less information than the tutorial. Choosing Call Tree instead of Cycles and Roots from the jump bar can help you find the areas of your code that are leaking memory.
I'm having strange effects with my app. I implemented my own PDF viewer. It shows ONE page at a time. Using Instruments Activity Monitor I see that my real memory is constantly at around 50MB.
After switching pages forth and back a couple of times I receive a memory warning level 0.
I do my best to react on it and sacrifice the low-res background image I'm rendering first to show something until CATiledLayer catches up.
Does not help. A few pages later I get memory warning level 1 and level 2 and after a few more pages my app gets killed with reason "9". Memory NEVER goes above 50MB!
Why do I get those warnings in the first place? There IS enough memory available.
This is happening on on iPad running iOS 4.3.
I don't think there's anything mysterious going on here -- which I'm sure is not what you wanted to hear. There are no absolute figures of "safe" amounts of memory to use. The rule is: when the OS tells you you're using too much, use less. It will jettison background processes first and in preference to your foreground app but there are still limits.
In the "olden days," you used to be lucky to get 20Mb. I'm sure you can safely get more than that on an iPad but, apparently, it's less than 50Mb.
You don't say how much memory you free by releasing the background image, but it seems that you need to be caching less data. You might also want to check Leaks (also in Instruments) to make sure you're releasing the objects you think you are.