|
||||
| manpages.info - online man pages | |
|||
|
||||
|
leaks (1) Table of Contents
Nameleaks - Search a process's memory for unreferenced malloc buffers
Synopsisleaks [-nocontext] [-nostacks] [-exclude symbol] pid | executable name
Descriptionleaks 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. Such buffers waste memory; removing them can reduce swapping and memory usage. Leaks are particularly dangerous for long-running programs, for eventually the leaks could fill memory and cause the application to crash.
leaks requires one parameter -- either the process id or executable name of the process to examine. It also takes several arguments for modifying its behavior.
For each leaked buffer that is found, leaks displays the address of the leaked memory and its size. If leaks can determine that the object is an instance of an Objective C or CoreFoundation class, it also specifies the name of the class. If the -nocontext option is not specified, it then displays a hexadecimal dump of the contents of the memory. If the MallocHeapLogging environment variable was set when the application was launched, leaks also displays a stack trace describing where the buffer was allocated.
The -nocontext option causes leaks to withhold a hex dump of the leaked memory. Although this information can be useful for recognizing the contents of the buffer and understanding why it might be leaked, it can also provide overwhelming detail. This flag will hopefully reduce your stress.
The -exclude option allows you to ignore functions that allocate memory which is from a well-known leak that you don't want to keep hearing about, or might be falsely labelled a leak by leaks. Any allocations which were called from the named function are excluded from leaks's output.
If the environment variable MallocStackLogging is set when the inspected program is started, leaks will also show the calling stack where the allocation occurred, providing essential hints about why the leak is occurring. The environment variable turns on debugging support in the standard malloc library; leaks then snoops at this information in the target to find the call stack. If the call stack information is being displayed, and you wish to suppress it, the -nostacks option causes leaks to turn off display of the call stack.
WeaknessesMemory allocated via Carbon's NewHandle() function and then leaked will not be noted by leaks. Thus, running leaks on a Carbon application will show only a subset of all possible leaks. The leaks reported will always be true leaks.
MallocDebug will correctly find leaked blocks that were allocated via NewHandle, and permits easier browsing of leaked blocks. However, MallocDebug does not detect leaks in circularly-linked structures or identify groups of leaked, connected nodes; leaks's pointer analysis can correctly identify such leaks.
See Alsomalloc(3) , heap(1) , malloc_history(1)
Similar graphical applications are part of the developer tools for the system. MallocDebug.app is a graphical application that also provides information about heap-allocated memory. It also performs leak analysis correctly for programs using the Carbon libraries.
|
|