LEAK(1)                                                   LEAK(1)

     NAME
          leak - examine family of processes for memory leaks

     SYNOPSIS
          leak [ -bs ] [ -f binary ] [ -r res ] [ -x width ] pid ...

     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 point-
          ers.  The set of root pointers is created by looking through
          the shared bss segment as well as each process's registers.

          Unless directed otherwise, leak prints, for each block, a
          line with five space-separated fields: the string block, the
          address of the block, the size of the block, and the first
          two words of the block.  Usually, the first two words of the
          block contain the malloc and realloc tags (see
          debugmalloc(2)), useful for finding who allocated the leaked
          blocks.

          If the -s option is given, leak will instead present a
          sequence of acid(1) commands that show each leaky allocation
          site.  A comment appears next to each command to indicate
          how many lost blocks were allocated at that point in the
          program.

          If the -b option is given, leak will print a Plan 9 image
          file graphically summarizing the memory arenas.  In the
          image, each pixel represents 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 representing 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

     Page 1                       Plan 9            (printed 12/28/24)

     LEAK(1)                                                   LEAK(1)

          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 nec-
          essary when inspecting processes started from stripped bina-
          ries.

     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.

               g% leak -s 8.out
               leak -s 229 230
               g% leak -s 8.out | rc
               src(0x0000bf1b); // 64
               src(0x000016f5); // 7
               src(0x0000a988); // 7
               g%

          View the memory usage graphic for the window system.

               g% leak -b rio | rc | page

     SOURCE
          /sys/lib/acid/leak
          /sys/src/cmd/aux/acidleak.c
          /rc/bin/leak

     BUGS
          Leak depends on the internal structure of the libc pool mem-
          ory allocator (see pool(2)). Since the ANSI/POSIX environ-
          ment uses a different allocator, leak will not work on APE
          programs.

     Page 2                       Plan 9            (printed 12/28/24)