Because unit testing exercises all code paths in a repeatable manner, you are more likely to find leaks than you would be if you were testing your code in a production environment.
Most of these guidelines are intended to be used with the leaks tool but some are also applicable for general use. The following guidelines can help you find memory leaks quickly in your program. Note: The leaks command-line tool is located in /usr/bin. For more information on malloc debugging options, see Enabling the Malloc Debugging Features. If the MallocStackLogging environment variable is set and you are running your application in gdb, leaks displays a stack trace describing where the buffer was allocated.
If you do not want to view the contents of each leaked buffer, you can specify the -nocontext option when calling leaks. If leaks can determine that the object is an instance of an Objective-C or Core Foundation object, it also displays the name of the object. For each leaked buffer it finds, leaks displays the following information: In OS X, the leaks command-line tool searches the virtual memory space of a process for buffers that were allocated by malloc but are no longer referenced. In Outline mode, the Leaks instrument displays leaks organized by call tree, which you can use to get information about the leaks in a particular branch of your code.įor more information about using the Instruments application, including more information about the information displayed by the Leaks instrument, see Instruments User Guide. Selecting an entry from this allocation history then shows the stack trace for that event in the Extended Detail pane of the document window. Selecting an entry in the table and clicking the arrow button next to the memory address shows the allocation history for the memory block at that address.
In Table mode, Instruments displays the complete list of leaked blocks, sorted by size. In the Detail pane, you can view leaked memory blocks using Table and Outline modes. If it does not find a reference to a block in one of these places, it deems the block a “leak” and displays the relevant information in the Detail pane. The Leaks instrument records all allocation events that occur in your application and then periodically searches the application’s writable memory, registers, and stack for references to any active memory blocks. The Leaks instrument provides leak-detection capabilities identical to those in the leaks command-line tool. To find leaks, create a new document template in Instruments and add the Leaks instrument to it. The Instruments application can be used to find leaks in both OS X and iPhone applications. In this example, overwriting the address in the pointer erases the reference to the original block of memory, making it impossible to release. If you allocate memory for embedded pointers in your code, make sure you release the memory for that pointer prior to deallocating the data structure itself.Īnother typical memory leak example occurs when you allocate memory, assign it to a pointer, and then assign a different value to the pointer without freeing the first block of memory. A typical memory leak occurs when you forget to deallocate memory for a pointer embedded in a data structure. If you call malloc or any routine that allocates memory, you must balance that call with a corresponding free. The malloc library can only reclaim the memory you tell it to reclaim. However, apps that mix the use of Objective-C objects and C-based structures must manage the ownership of objects more directly to ensure that the objects are not leaked. For apps that use only Objective-C objects, the compiler’s ARC feature deallocates objects for you and generally avoids the problem of memory leaks. Leaked memory eventually forces the system to allocate additional virtual memory pages for the application, the allocation of which could have been avoided by reclaiming the leaked memory.įor apps that use malloc, memory leaks are bugs and should always be fixed. Leaks waste space by filling up pages of memory with inaccessible data and waste time due to extra paging activity. Memory leaks are blocks of allocated memory that the program no longer references.