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