how to use Dtrace to check malloc on Solaris 10?

Question

I meet a troublesome bug about memory usage, so I want to use Dtrace to check malloc and free on Solaris 10.

I use the following command

dtrace -l | grep malloc

The output is:

7000 fbt unix prom_malloc entry 7001 fbt unix prom_malloc return 7141 fbt genunix cacl_malloc entry 7142 fbt genunix cacl_malloc return 12319 fbt genunix rmallocmap_wait entry 12320 fbt genunix rmallocmap_wait return 13078 fbt genunix rmalloc_wait entry 13079 fbt genunix rmalloc_wait return 13526 fbt genunix rmallocmap entry 13527 fbt genunix rmallocmap return 16846 fbt genunix rmalloc entry 16847 fbt genunix rmalloc return 25931 fbt tmpfs tmp_memalloc entry 25932 fbt tmpfs tmp_memalloc return

It seems there is no malloc.

I have checked Solaris Internal, and found the malloc calls sbrk. So I use the following command:

dtrace -l | grep sbrk

But there is nothing found.

So how can I use Dtrace to check malloc on Solaris 10?

I guess this tool will be useful for you:theunixshell.blogspot.com/2013/11/… — Vijay
– Vijay, Commented Dec 13, 2013 at 6:01
@Vijay: Thanks very much for your comments, and it is a very cool tool! — Nan Xiao
– Nan Xiao, Commented Dec 13, 2013 at 6:40
drop me a mail [email protected] or comment on the blog with your email — Vijay
– Vijay, Commented Dec 16, 2013 at 10:17

jlliagre · Accepted Answer · 2018-10-22 16:49:16Z

There are various tools that already implement the logic required to identify memory leaks under Solaris,

libumem & mdb (UMEM_DEBUG=default UMEM_LOGGING=transaction LD_PRELOAD=libumem.so.1 then mdb's ::findleaks)
dbx (check -leaks)

Should you still want to go the dtrace way, you need to trace the process you suspect to leak memory using the pid provider. You searched the kernel probes with dtrace -l and found nothing but this is expected as the kernel does not implement malloc or brk. They are userland functions located in the C standard library.

This script will trace every malloc and free calls by a program:

dtrace -qn ' pid$target:libc:malloc:entry { self->size=arg0; } pid$target:libc:malloc:return /self->size/ { printf("malloc(%d)=%p\n",self->size,arg1); self->size=0; } pid$target:libc:free:entry { printf("free(%p)\n",arg0); } ' -c program_to_trace

For more in-depth examples, have a look to http://ewaldertl.blogspot.fr/2010/09/debugging-memory-leaks-with-dtrace-and.html and http://www.joyent.com/blog/bruning-questions-debugging

Would you mind explaining why the return pointer is in arg1 instead of arg0? I'm pretty green at dtrace but for something like syscall::open:return, the file descriptor is in arg0
@genghiskhan That's by design. I'm using the pid provider which has a different behavior than the syscall provider you are referring to. With the pid provider A return probe fires when the traced function returns or makes a tail call to another function. The value for arg0 is the offset in the function of the return instruction; arg1 holds the return value.. Note that with the syscall provider, the return value is both in arg0 and arg1.

Petros Pissias · Accepted Answer · 2018-11-17 06:58:25Z

For example, in order to trace all malloc calls with dtrace, by printing each allocation you would write (to a file named trace-malloc.d in this example) a script like below:

#!/usr/sbin/dtrace -s pid$1::malloc:entry { self->trace = 1; self->size = arg0; } pid$1::malloc:return /self->trace == 1/ { /* log the memory allocation */ printf("<__%i;%Y;%d;malloc;0x%x;%d;\n", i++, walltimestamp, tid, arg1, self->size); ustack(50); printf("__>\n\n"); self->trace = 0; self->size = 0; }

and then call it by passing the process id of the process you want to trace, for example:

./trace-malloc.d 12345

In complex programs there are very frequent memory allocations and de-allocations so I've written a small program to help me identify memory leaks with dtrace. Each memory operation with malloc / calloc / realloc and free is traced and then an analysis program reads and processes all the traces and points out suspected memory leaks, also using various heuristics to point out strongly suspected memory leaks. If you are interested you can check it out here:

https://github.com/ppissias/DTLeakAnalyzer.

Just linking to your own library or tutorial is not a good answer. Linking to it, explaining why it solves the problem, providing code/process on how to do so and disclaiming that you wrote it makes for a better answer. See: What signifies “Good” self promotion?
@Shree The post starts with "I've written". So, isn't that a clear statement who wrote the tool?
@AdrianW I always imagine answer without link.If with out link it's address a question and link is for only reference I am not flagged the answer.
Hi, thanks for the feedback of the reply, I have changed it accordingly to also include an answer to the question. The intention was to help someone else who has the same problem, as I was also searching for available tools using dtrace not too long ago.

Collectives™ on Stack Overflow

how to use Dtrace to check malloc on Solaris 10?

2 Answers 2

2 Comments

4 Comments

Hot Network Questions

Collectives™ on Stack Overflow

2 Answers 2

2 Comments

4 Comments

Related