Here are some links that might help: http://forums.sun.com/thread.jspa?threadID=5075270&tstart=-1
And there seems to be some kind of a guide for how to do it at this link in Sun's documentation pages: http://docs.sun.com/source/820-4221/index.html >From which I got the following quote: "A memory leak is a dynamically allocated block of memory that has no pointers pointing to it anywhere in the data space of the program. Such blocks are orphaned memory. Because there are no pointers pointing to the blocks, programs cannot reference them, much less free them. DTrace might be used to detect the memory leaks in applications. However, the user needs to pay close attention to the output of DTrace specially if malloc()() and free()() functions are called extensively in an application. The hello.c program is used to show the proper usage of both DTrace and the Sun Studio dbx debugger. .... The mfs.d script uses the pid provider to match up the memory addresses for malloc()() and free()() function calls. #!/usr/sbin/dtrace -s pid$target:$1:malloc:entry { ustack(); } pid$target:$1:malloc:return { printf("%s: %x\n", probefunc, arg1); } pid$target:$1:free:entry { printf("%s: %x\n", probefunc, arg0); } The ustack()() action records a user stack trace to the directed buffer. The arg1 in the pid$target:$1:malloc:return probe is the address of the newly allocated space that returns by the malloc()() function. The arg0 in the pid$target:$1:free:entry probe is the address of the space that needs to be deleted by the free()() function. he free()() function is not called for the 0x1001010a0 and 0x1001028b0 addresses. Hence, you might assume that there are memory leaks for those addresses. However, as it will be described shortly, all memory allocations might not need to be deleted before the program ends. The address 0x1001010a0 or the local variable in the memory_leak() function is the memory leak, since it has no pointers pointing to it anywhere in the data space of the program. -- This message posted from opensolaris.org
