LEAK(1)LEAK(1)NAME
leak, kmem, umem - help find memory leaks
SYNOPSIS
leak [ -abcds ] [ -f binary ] [ -r res ] [ -x width ] pid ...
kmem [ kernel ]
umem pid [ textfile ]
DESCRIPTION
Leak examines the named processes, which should be sharing their data
and bss segments, for memory leaks. It uses a mark and sweep-style
algorithm to determine which allocated blocks are no longer reachable
from the set of root pointers. The set of root pointers is created by
looking through the shared bss segment as well as each process's regis‐
ters.
Unless directed otherwise, leak prints, for each block, a line with
seven space-separated fields: the string block, the address of the
block, the size of the block, the first two words of the block, and the
function names represented by the first two words of the block. Usu‐
ally, the first two words of the block contain the malloc and realloc
tags (see malloc(2)), useful for finding who allocated the leaked
blocks.
If the -s or the -c option is given, leak will instead present a
sequence of acid(1) commands that show each leaky allocation site.
With -s a comment appears next to each command to indicate how many
lost blocks were allocated at that point in the program. With -c the
comments are extended to indicate also the total number of bytes lost
at that point in the program, and an additional comment line gives the
overall total number of bytes.
If the -a option is given, leak will print information as decribed
above, but for all allocated blocks, not only leaked ones. If the -d
option is given, leak will print information as decribed above, but for
all free blocks, i.e. those freed, or those that are not yet in use
(fragmentation?). The -a and -d options can be combined.
If the -b option is given, leak will print a Plan 9 image file graphi‐
cally summarizing the memory arenas. In the image, each pixel repre‐
sents res (default 8) bytes. The color code is:
dark blue Completely allocated.
bright blue Contains malloc headers.
bright red Contains malloc headers for leaked memory.
dark red Contains leaked memory.
yellow Completely free
white Padding to fill out the image. The bright pixels repre‐
senting headers help in counting the number of blocks.
Magnifying the images with lens(1) is often useful.
If given a name rather than a list of process ids, leak echoes back a
command-line with process ids of every process with that name.
The -f option specifies a binary to go on the acid(1) command-line used
to inspect the processes, and is only necessary when inspecting pro‐
cesses started from stripped binaries.
Umem prints a summary of all allocated blocks in the process with id
pid. Each line of the summary gives the count and total size of blocks
allocated at an allocation point. The list is sorted by count in
decreasing order. Umem prints summarizes all allocations, not just
memory leaks, but it is faster and requires less memory than leak .
Kmem is like umem but prints a summary for the running kernel.
EXAMPLES
List lost blocks in 8.out. This depends on the fact that there is only
once instance of 8.out running; if there were more, the output of leak
-s 8.out would need editing before sending to the shell.
% leak -s 8.out
leak -s 229 230
% leak -s 8.out | rc
src(0x0000bf1b); // 64
src(0x000016f5); // 7
src(0x0000a988); // 7
%
View the memory usage graphic for the window system.
% leak -b rio | rc | page
List the top allocation points in the kernel, first by count and then
by total size:
% kmem | sed 10q
% kmem | sort -nr +1 | sed 10q
SOURCE
/sys/lib/acid/leak
/sys/src/cmd/aux/acidleak.c
/rc/bin/leak
/rc/bin/kmem
/rc/bin/umem
SEE ALSOgetcallerpc(2), setmalloctag in malloc(2)BUGS
Leak and kmem depend on the internal structure of the libc pool memory
allocator (see pool(2)). Since the ANSI/POSIX environment uses a dif‐
ferent allocator, leak will not work on APE programs.
Leak is not speedy, and acidleak can consume more memory than the
process(es) being examined.
These commands require /sys/src/libc/port/pool.acid to be present and
generated from pool.c.
LEAK(1)
