Mandalika's scratchpad [ Work blog @Oracle | Stock Market Notes | My Music Compositions ]

Old Posts: 09.04  10.04  11.04  12.04  01.05  02.05  03.05  04.05  05.05  06.05  07.05  08.05  09.05  10.05  11.05  12.05  01.06  02.06  03.06  04.06  05.06  06.06  07.06  08.06  09.06  10.06  11.06  12.06  01.07  02.07  03.07  04.07  05.07  06.07  08.07  09.07  10.07  11.07  12.07  01.08  02.08  03.08  04.08  05.08  06.08  07.08  08.08  09.08  10.08  11.08  12.08  01.09  02.09  03.09  04.09  05.09  06.09  07.09  08.09  09.09  10.09  11.09  12.09  01.10  02.10  03.10  04.10  05.10  06.10  07.10  08.10  09.10  10.10  11.10  12.10  01.11  02.11  03.11  04.11  05.11  07.11  08.11  09.11  10.11  11.11  12.11  01.12  02.12  03.12  04.12  05.12  06.12  07.12  08.12  09.12  10.12  11.12  12.12  01.13  02.13  03.13  04.13  05.13  06.13  07.13  08.13  09.13  10.13  11.13  12.13  01.14  02.14  03.14  04.14  05.14  06.14  07.14  09.14  10.14  11.14  12.14  01.15  02.15  03.15  04.15  06.15  09.15  12.15  01.16  03.16  04.16  05.16  06.16  07.16  08.16  09.16  12.16  01.17  02.17  03.17  04.17  06.17  07.17  08.17  09.17 


Sunday, November 06, 2005
 
Sun Studio: Gathering memory allocations/leaks data, from a running process

One simple way of collecting this information is with the runtime checking (RTC) feature of dbx, as described in Investigating memory leaks with dbx. Yet another way is to use the collector to get this data, if the process is already running under dbx.

Note that running the application under collect tool, with heap tracing on {with -H on option}, produces overwhelming data which includes all the leaks that occured in the life span of the process. So, if we need to collect the data only for a specific component of the application, clearly running the application under collect is not a good choice.

Steps for collecting data from a running (32-bit) process, with dbx and collector:

In one window:
  1. Preload libcollector.so and set the path to the library, using LD_PRELOAD and LD_LIBRARY_PATH respectively

  2. Run the program/application

In another terminal window:
  1. Get the process ID (aka PID)

  2. If dbx is already running, attach the process to dbx; else start dbx with the PID of the application

  3. Enable data collection with collector enable command

  4. Create/open a new experiment with collector store filename <experiment_name>.er command

  5. Turn the heap tracing on, with collector heaptrace on command. By default, heap tracing is off

  6. Start the data collection by resuming the process with cont command of dbx

  7. Run some relevant test scenarios to capture the memory allocations and leaks, for a specific component of interest

  8. Either detach the process or stop it, when the data collection is done

  9. Finally analyze the data with er_print command line tool, or analyzer graphical tool

The following simple example shows the execution steps outlined above

eg.,
% cat memleaks.c     <- source code
#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(3);
}
}

% /opt/SS10/SUNWspro/prod/bin/cc -g -o memleaks memleaks.c

% setenv LD_LIBRARY_PATH /opt/SS10/SUNWspro/prod/lib/dbxruntime/libcollector.so:$LD_LIBRARY_PATH
% setenv LD_PRELOAD /opt/SS10/SUNWspro/prod/lib/dbxruntime/libcollector.so

% ./memleaks

Address of x = 134613536, y = 134613944
New address of x = 134614152, y = 134614272

Address of x = 134616832, y = 134617240
New address of x = 134617448, y = 134614272

...
...

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
<- start the data collection
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

<- stop the data collection

In another window:
% ps -eaf | grep memleaks
techno 11174 10744 0 19:39:09 syscon 0:00 ./memleaks

% dbx - 11174
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 libcollector.so
Reading libc.so.1
Reading libdl.so.1
Attached to process 11174
stopped in ___nanosleep at 0xd2642a75
0xd2642a75: ___nanosleep+0x0015: jae ___nanosleep+0x23 [ 0xd2642a83, .+0xe ]
Current function is main
24 sleep(3);

(dbx) collector enable
(dbx) collector heaptrace on

(dbx) cont
Creating experiment database test.2.er ... <- If no experiment name is specified with
collector store filename <exptname>.er command, a default experiment will be created

^C <- stopped it after 15 sec
execution completed, exit code is 138902584
(dbx) quit

% er_print test.2.er
test.2.er: Experiment has warnings, see header for details

(er_print) func
Functions sorted by metric: Inclusive Bytes Leaked

Incl. Incl. Excl. Incl. Name
Bytes Leaks User CPU User CPU
Leaked sec. sec.
3500 15 0. 0. <Total>
3500 15 0. 0. _start
3500 15 0. 0. allocate
3500 15 0. 0. main
3500 15 0. 0. malloc
0 0 0. 0. ___nanosleep

(er_print) source allocate
Source file: ./memleaks.c
Object file: ./memleaks
Load Object: ./memleaks

Incl. Incl. Excl. Incl.
Bytes Leaks User CPU User CPU
Leaked sec. sec.
1. #include <stdlib.h>
2. #include <unistd.h>
3. #include <stdio.h>
4.
0 0 0. 0. 5. void allocate() {

6. int *x;
7. char *y;
8.
2000 5 0. 0. 9. x = (int *) malloc(sizeof(int) * 100);
1000 5 0. 0. 10. y = (char *) malloc (sizeof(char) * 200);

11.
0 0 0. 0. 12. printf("\nAddress of x = %u, y = %u", x, y);
13.
500 5 0. 0. 14. x = (int *) malloc (sizeof(int) * 25);
0 0 0. 0. 15. y = (char *) malloc (sizeof(char) * 25);
16.
0 0 0. 0. 17. printf("\nNew address of x = %u, y = %u\n", x, y);
0 0 0. 0. 18. free (y);
0 0 0. 0. 19. }
20.
0 0 0. 0. 21. void main() {

22. while (1) {
## 3500 15 0. 0. 23. allocate(); <- malloc() was called 15 times,
requesting for a total of 3500 bytes, with no corresponding code>free()

0 0 0. 0. 24. sleep(3);
0 0 0. 0. 25. }
0 0 0. 0. 26. }


(er_print) leaks <- show potential memory leaks
Summary Results: Distinct Leaks = 3, Total Instances = 15, Total Bytes Leaked = 3500

Leak #1, Instances = 5, Bytes Leaked = 2000
malloc + 0x000000BA
allocate + 0x00000018, line 9 in "memleaks.c"
main + 0x00000013, line 23 in "memleaks.c"
_start + 0x00000079

Leak #2, Instances = 5, Bytes Leaked = 1000
malloc + 0x000000BA
allocate + 0x00000028, line 10 in "memleaks.c"
main + 0x00000013, line 23 in "memleaks.c"
_start + 0x00000079

Leak #3, Instances = 5, Bytes Leaked = 500
malloc + 0x000000BA
allocate + 0x0000004A, line 14 in "memleaks.c"
main + 0x00000013, line 23 in "memleaks.c"
_start + 0x00000079

(er_print) allocs <- show memory allocations
Summary Results: Distinct Allocations = 4, Total Instances = 20, Total Bytes Allocated = 3625

Allocation #1, Instances = 5, Bytes Allocated = 2000
malloc + 0x000000BA
allocate + 0x00000018, line 9 in "memleaks.c"
main + 0x00000013, line 23 in "memleaks.c"
_start + 0x00000079

Allocation #2, Instances = 5, Bytes Allocated = 1000
malloc + 0x000000BA
allocate + 0x00000028, line 10 in "memleaks.c"
main + 0x00000013, line 23 in "memleaks.c"
_start + 0x00000079

Allocation #3, Instances = 5, Bytes Allocated = 500
malloc + 0x000000BA
allocate + 0x0000004A, line 14 in "memleaks.c"
main + 0x00000013, line 23 in "memleaks.c"
_start + 0x00000079

Allocation #4, Instances = 5, Bytes Allocated = 125
malloc + 0x000000BA
allocate + 0x00000057, line 15 in "memleaks.c"
main + 0x00000013, line 23 in "memleaks.c"
_start + 0x00000079

(er_print) quit

Detailed information is in Sun Studio Performance Analyzer document, hosted on docs.sun.com.

Related blog posts:
  1. Sun Studio: Investigating memory leaks with dbx
  2. Sun Studio: Investigating memory leaks with Collector/Analyzer
___________________

Technorati tags: |


Comments: Post a Comment

Links to this post:

Create a Link



<< Home


2004-2017 

This page is powered by Blogger. Isn't yours?