I'm sure it's a memory leak, and I'm certainly no expert in memory allocation, but instruments says I have a memory leak of zero bytes...
Can someone explain what exactly that means?
The leaked object (including the responsible party that initiates it) should appear in the lower half part of the Instruments window, once you have selected the "Leaks Discovered".
Doing an "Analyze" (Command + I) in XCode will also show possible memory leaks in your code.
Related
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.
Is there a good tutorial on interpretation and problem-solving with Guard Malloc?
I'm getting message like "Failed to VM allocate 262144 bytes", and I have no idea what this means. Initially I thought it was the lack of RAM in the system, but maybe not so. If it is a problem I desperately need to learn how to interpret and catch the error.
Another question I have with Guard Malloc is whether it guards memory allocated in C codes of the project (it should right? considering the name) or only applying only to Objective-C? The reason I asked is that I just found out NSZombieEnabled only applies to Obj-C.
Help very much appreciated. I've been messing with likely memory errors for days. And I've not been able to compile Valgrind for iOS yet.
1) I've been chalking up allocation failures with guard malloc on to address space exhaustion -- every allocation takes up at least a page of address space that can't be reused. Uses of memory that is not currently allocated will crash in guard malloc, not cause allocation failures.
2) as the name suggests, guard malloc replaces the implementation of malloc(3), so C code that uses malloc will be checked.
Note that guard malloc is not a silver bullet. You still have to expose your app's bugs through testing; guard malloc just causes crashes to happen earlier and more reliably.
You might also want to read "man libgmalloc".
I was seeing this running on the ios simulator with Guard Malloc set. Choosing the 64-bit device for the simulator stopped the error coming up.
"Failed to VM allocate" is lack of available RAM, as you suspected.
I can only reliably use Guard Malloc when I close every other program on my mac, and even then it sometimes fails with greedy programs that use a lot of memory.
You'll need to:
Buy more RAM
Close all other running programs on your mac
Reduce the memory used by your program through profiling/optimization.
Memory leak snapshot with no "Hide system libraries selected"-
Memory leak snapshot with "Hide system libraries selected"-
Do I need to worry for these leaks as after many memory cycles I have come up to this point wherein I do not find a memory leak source in my application.
Is my understanding OK ?
And this image shows memory leak in cycles and roots mode -
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.
How does the XCode Instrument Leak tool figure out if an object is a leak or just something not released yet?
I'm pretty new to Objective C, the leak tool detects a leak in the code I work with. But the code looks sound to me. So just wondering how much can I trust this tool?
A "leak" as an object that's still allocated, but your application no longer has a reference
pointing to that object. Since you no longer have a reference, there's no way you will be able to release the object, thus it's a leak.
As the leaks(1) man page says:
leaks identifies leaked memory -- memory that the application has allocated, but has been lost and cannot be freed. Specifically, leaks examines a specified process's memory for values that may be pointers to malloc-allocated buffers. Any buffer reachable from a pointer in writable memory, a register,
or on the stack is assumed to be memory in use. Any buffer reachable from a pointer in a reachable
malloc-allocated buffer is also assumed to be in use. The buffers which are not reachable are leaks;
the buffers could never be freed because no pointer exists in memory to the buffer, and thus free()
could never be called for these buffers
You might also want to look into the ObjectAlloc tool in Instruments.