Some time back I have had a blog entry with the title
Sun Studio: Investigating memory leaks with Collector/Analyzer. It is possible to check memory leaks {along with memory use and memory access checking} with the Sun Studio debugger tool,
dbx
, as well. This blog post attempts to show the steps involved in generating the memory leak report, with a simple example (taken from Collector/Analyzer example).
Runtime checking with dbx
dbx
uses the word
runtime checking (RTC) for detecting runtime errors, like memory leaks and memory access errors. Extensive material about RTC is available in the
Debugging a Program With dbx document, under chapter
Using Runtime Checking.
For the runtime checking feature to work properly, the process must have
rtcaudit.so
preloaded when it starts.
To preload rtcaudit.so:
% setenv LD_AUDIT <path-to-rtcaudit-lib>/rtcaudit.so
Turn off mutex tracking with
dbxenv mt_sync_tracking off
, to avoid running into the bug
thread_db synchronization tracking causes cond_wait failure and hangs. Even if you don't, tt forces you to turn it off, anyway.
Unset
LD_AUDIT
once the data collection is done.
Here's an example, with annotated commentary:
% more memleaks.c <= source file
#include <stdlib.h>
#include <unistd.h>
#include <stdio.h>
void allocate() {
int *x;
char *y;
x = (int *) malloc(sizeof(int) * 100);
y = (char *) malloc (sizeof(char) * 200);
printf("\nAddress of x = %u, y = %u", x, y);
x = (int *) malloc (sizeof(int) * 25);
y = (char *) malloc (sizeof(char) * 25);
printf("\nNew address of x = %u, y = %u\n", x, y);
free (y);
}
void main() {
while (1) {
allocate();
sleep(1);
}
}
% which cc <= Sun Studio 10 C compiler
/software/SS10/SUNWspro/prod/bin/cc
% cc -g -o memleaks memleaks.c <= Compile the code with debug (-g
) flag
% setenv LD_AUDIT /software/SS9/SUNWspro/prod/lib/dbxruntime/rtcaudit.so <= Pre-load rtcaudit library
% ./memleaks
Address of x = 134621928, y = 134622336
New address of x = 134622544, y = 134614272
Address of x = 134622656, y = 134623064
New address of x = 134623272, y = 134614272
...
...
In another window:
% ps -eaf | grep memleaks
techno 11174 10744 0 19:39:09 syscon 0:00 ./memleaks
% dbx - 11174 <= Attach the process to the debugger, dbx
For information about new features see `help changes'
To remove this message, put `dbxenv suppress_startup_message 7.4' in your .dbxrc
Reading -
Reading ld.so.1
Reading libc.so.1
Reading rtcaudit.so
Reading libmapmalloc.so.1
Reading libgen.so.1
Reading libdl.so.1
Reading libm.so.2
Reading libc_psr.so.1
Reading rtcboot.so
Reading librtc.so
(dbx) dbxenv mt_sync_tracking off <= Turn off mutex tracking
(dbx) check -leaks <= Turn on memory leak checking
leaks checking - ON
RTC: Enabling Error Checking...
RTC: Running program...
(dbx) cont <= Resume program execution
Address of x = 134623384, y = 134623792
New address of x = 134624000, y = 134614272
Address of x = 134624112, y = 134624520
New address of x = 134624728, y = 134614272
Address of x = 134624840, y = 134625248
New address of x = 134625456, y = 134614272
Address of x = 134625568, y = 134625976
New address of x = 134626184, y = 134614272
Address of x = 134626296, y = 134626704
New address of x = 134626912, y = 134614272
^C <= Interrupt the execution with Ctrl-C, to get intermediate leak report
dbx: warning: Interrupt ignored but forwarded to child.
signal INT (Interrupt) in ___nanosleep at 0xed1bc7dc
0xed1bc7dc: ___nanosleep+0x0004: ta 8
Current function is main
24 sleep(1);
(dbx) showleaks <= showleaks
reports new memory leaks since the last showleaks
command
Checking for memory leaks...
Actual leaks report (actual leaks: 15 total size: 3500 bytes)
Total Num of Leaked Allocation call stack
Size Blocks Block
Address
========== ====== =========== =======================================
2000 5 - allocate < main
1000 5 - allocate < main
500 5 - allocate < main
Possible leaks report (possible leaks: 0 total size: 0 bytes)
(dbx) cont <= Continue the execution of the program
Address of x = 139208, y = 139632
New address of x = 139856, y = 139984
Address of x = 140040, y = 140464
New address of x = 140688, y = 135824
Address of x = 140816, y = 141240
New address of x = 141464, y = 136656
Address of x = 141592, y = 142016
New address of x = 142240, y = 137488
^C <= Interrupt the execution with Ctrl-C, to get intermediate leak report
dbx: warning: Interrupt ignored but forwarded to child.
signal INT (Interrupt) in ___nanosleep at 0xed1bc7dc
0xed1bc7dc: ___nanosleep+0x0004: ta 8
Current function is main
24 sleep(1);
(dbx) showleaks <= showleaks
reports new memory leaks since the last showleaks
command
Checking for memory leaks...
Actual leaks report (actual leaks: 12 total size: 2800 bytes)
Total Num of Leaked Allocation call stack
Size Blocks Block
Address
========== ====== =========== =======================================
1600 4 - allocate < main
800 4 - allocate < main
400 4 - allocate < main
Possible leaks report (possible leaks: 0 total size: 0 bytes)
(dbx) showleaks -a <= showleaks -a
show all the leaks generated so far,
not just the leaks since the last showleaks
command
Checking for memory leaks...
Actual leaks report (actual leaks: 27 total size: 6300 bytes)
Total Num of Leaked Allocation call stack
Size Blocks Block
Address
========== ====== =========== =======================================
3600 9 - allocate < main
1800 9 - allocate < main
900 9 - allocate < main
Possible leaks report (possible leaks: 0 total size: 0 bytes)
(dbx) showleaks -v <= Verbose report, since the last showleaks
command. Default: Non verbose report
Checking for memory leaks...
Actual leaks report (actual leaks: 12 total size: 2800 bytes)
Memory Leak (mel):
Found 4 leaked blocks with total size 1600 bytes
At time of each allocation, the call stack was:
[1] allocate() at line 9 in "memleaks.c"
[2] main() at line 23 in "memleaks.c"
Memory Leak (mel):
Found 4 leaked blocks with total size 800 bytes
At time of each allocation, the call stack was:
[1] allocate() at line 10 in "memleaks.c"
[2] main() at line 23 in "memleaks.c"
Memory Leak (mel):
Found 4 leaked blocks with total size 400 bytes
At time of each allocation, the call stack was:
[1] allocate() at line 14 in "memleaks.c"
[2] main() at line 23 in "memleaks.c"
Possible leaks report (possible leaks: 0 total size: 0 bytes)
(dbx) func allocate <= Change the current function to allocate
(dbx) list 9 <= List line number 9 of function allocate
9 x = (int *) malloc(sizeof(int) * 100);
(dbx) list 10
10 y = (char *) malloc (sizeof(char) * 200);
(dbx) list 14
14 x = (int *) malloc (sizeof(int) * 25);
(dbx) func main
(dbx) list 23
23 allocate();
(dbx)
In short, memory leak report can be generated as follows with the help of RTC feature of dbx:
- Compile your program with
-g
(debug) flag, to get source line numbers in the runtime checking error messages. However it is not mandatory to compile with -g
to do runtime checking (RTC)
- Pre-load RTC library, rtcaudit:
setenv LD_AUDIT <path-to-rtcaudit-lib>/rtcaudit.so
- Load the program with dbx or attach the running process to dbx with
dbx - <pid>
- Turn off mutex tracking with
dbxenv mt_sync_tracking off
-- I have no clue why dbx didn't like mutex tracking on; and there's no relevant documentation anywhere in Sun documentation site. Perhaps Chris Quenelle can explain this
- Turn on the runtime checking for memory leaks with
check -leaks
command
- Run the program with
run
command, if it is not running already
- Occasionally interrupt the execution with Ctrl-C, and get the leak report with any of
showleaks, showleaks -a, showleaks -v
commands
- Detach the process, once the data has been collected
- Unset the LD_AUDIT variable.
unsetenv LD_AUDIT
__________________
Technorati tags:
Sun Studio |
dbx