[ Previous | Next | Table of Contents | Index | Library Home | Legal | Search ]

Performance Management Guide


Finding Memory-Leaking Programs

A memory leak is a program error that consists of repeatedly allocating memory, using it, and then neglecting to free it. A memory leak in a long-running program, such as an interactive application, is a serious problem, because it can result in memory fragmentation and the accumulation of large numbers of mostly garbage-filled pages in real memory and page space. Systems have been known to run out of page space because of a memory leak in a single program.

A memory leak can be detected with the svmon command, by looking for processes whose working segment continually grows. A leak in a kernel segment can be caused by an mbuf leak or by a device driver, kernel extension, or even the kernel. To determine if a segment is growing, use the svmon command with the -i option to look at a process or a group of processes and see if any segment continues to grow.

Identifying the offending subroutine or line of code is more difficult, especially in AIXwindows applications, which generate large numbers of malloc() and free() calls. C++ provides a HeapView Debugger for analyzing/tuning memory usage and leaks. Some third-party programs exist for analyzing memory leaks, but they require access to the program source code.

Some uses of the realloc() subroutine, while not actually programming errors, can have the same effect as a memory leak. If a program frequently uses the realloc() subroutine to increase the size of a data area, the working segment of the process can become increasingly fragmented if the storage released by the realloc() subroutine cannot be reused for anything else.

Use the disclaim() system call and free() call to release memory that is no longer required. The disclaim() system call must be called before the free() call. It wastes CPU time to free memory after the last malloc() call, if the program will finish soon. When the program terminates, its working segment is destroyed and the real memory page frames that contained working segment data are added to the free list. The following example is a memory-leaking program; its Inuse, Pgspace, and Address Range of the private working segment are continually growing.

An output example from AIX 4.3.2 follows (the example is the same with AIX 4.3.3 and later, although the output format is different):

# svmon -P 19556 -i 1 3
  Pid                         Command        Inuse        Pin      Pgspace
19556                          pacman         3085          1         1580
Pid:  19556
Command:  pacman
Segid  Type  Description          Inuse    Pin  Pgspace  Address Range
  9c8  pers  /dev/hd2:53289           1      0        0  0..0
  aaf  work  lib data                12      0        6  0..1081
  909  work  shared library text   1502      0        7  0..65535
 1eba  work  private               1568      1     1567 0..1562:65313..65535
 16f3  pers  code,/dev/lv01:12302      2      0        0  0..1
 
 
  Pid                         Command        Inuse        Pin      Pgspace
19556                          pacman         3114          1         1609
Pid:  19556
Command:  pacman
Segid  Type  Description          Inuse    Pin  Pgspace  Address Range
  9c8  pers  /dev/hd2:53289           1      0        0  0..0
  aaf  work  lib data                12      0        6  0..1081
  909  work  shared library text   1502      0        7  0..65535
 1eba  work  private               1597      1     1596 0..1591:65313..65535
 16f3  pers  code,/dev/lv01:12302      2      0        0  0..1
 
 
  Pid                         Command        Inuse        Pin      Pgspace
19556                          pacman         3149          1         1644
Pid:  19556
Command:  pacman
Segid  Type  Description          Inuse    Pin  Pgspace  Address Range
  9c8  pers  /dev/hd2:53289           1      0        0  0..0
  aaf  work  lib data                12      0        6  0..1081
  909  work  shared library text   1502      0        7  0..65535
 1eba  work  private               1632      1     1631 0..1626:65313..65535
 16f3  pers  code,/dev/lv01:12302      2      0        0  0..1


[ Previous | Next | Table of Contents | Index | Library Home | Legal | Search ]