HP-UX HB v13.00 Ch-11 - Software Development

HP-UX Handbook Rev 13.00 Page 83 (of 101)
Chapter 11 Software Development
October 29, 2013
Memory Leaks
If process memory hits a system limit despite having it already increased to a reasonable value,
the process is likely to have a memory leak, which means it allocates memory but fails to free it
when it is no longer needed. In this case, further increasing the limits will only result in the
program taking longer until the limit is hit, but the problem is not gone. Memory leaks are almost
always coding errors and typically must be corrected by the programmers.
There are several non-HP tools available on the market that can help finding memory leaks in the
process heap. But also the current versions of WDB [1] have heap checking features. To find
leaks, run the program under the debugger and switch on the heap-checking:
$ gdb a.out
HP gdb 5.0 for PA-RISC 1.1 or 2.0 (narrow), HP-UX 11.11
:
(gdb) set heap-check on
(gdb) r
:
[interrupt at any time with CTRL-C, or wait until a breakpoint is hit]
:
(gdb) info leaks
Scanning for memory leaks...
Execution of code located on a program's stack is not permitted.
cmd: /tmp/a.out
30000 bytes leaked in 3 blocks
No. Total bytes Blocks Address Function
0 30000 3 0x4042d2b8 f10()
(gdb) info leak 0
30000 bytes leaked in 3 blocks (100.00% of all bytes leaked)
These range in size from 10000 to 10000 bytes and are allocated
#0 f10() at x.c:7
:
#10 main() at x.c:20
(gdb)
info leaks lists all leaks that have been detected, and info leak <num> shows the details of a
certain leak, including the stacktrace from the location where malloc() was called. More details
about the heap-checking features of gdb can be found in the gdb online help on any HP-UX
system with a recent gdb installed:
file:///opt/langtools/wdb/doc/html/wdb/C/index.html