-------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: malloc_source.txt URL: <http://mail.opensolaris.org/pipermail/dtrace-discuss/attachments/20051207/8f25be8b/attachment.txt>
On Wed, Dec 07, 2005 at 02:09:56AM +0530, Ashutosh Kumar wrote:> What a Dscript look like to know which all functions in user land are > causing malloc?How about this: # dtrace -n pid<pid>::malloc:entry''{ @[ustack(2)] = count(); }'' dtrace: description ''pid167267::malloc:entry'' matched 2 probes ^C ... libc.so.1`malloc libmozjs.so`JS_malloc+0x24 7341 libc.so.1`malloc libCrun.so.1`__1c2n6FI_pv_+0x28 62251 Adam -- Adam Leventhal, Solaris Kernel Development http://blogs.sun.com/ahl
Adam Leventhal''s email at 12/6/2005 5:18 PM, said:> On Wed, Dec 07, 2005 at 02:09:56AM +0530, Ashutosh Kumar wrote: > >>What a Dscript look like to know which all functions in user land are >>causing malloc? > > > How about this: > > # dtrace -n pid<pid>::malloc:entry''{ @[ustack(2)] = count(); }'' > dtrace: description ''pid167267::malloc:entry'' matched 2 probes > ^C > ... > libc.so.1`malloc > libmozjs.so`JS_malloc+0x24 > 7341 > > libc.so.1`malloc > libCrun.so.1`__1c2n6FI_pv_+0x28 > 62251 >This here is why I generally go ustack(4). Demangling this to "new" isn''t terribly helpful. In the case of C++ constructors and new(), ustack(4) usually gives good success in getting the caller you are interested in without too much fluff in a deep stack to make for an unmanageable number of stacks that all are really the same allocation point. Thanks, Jarod
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1"
http-equiv="Content-Type">
<title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
Thanks Adam,<br>
<br>
I am interested in knowing which functions in the user application are
causing this malloc?<br>
<br>
For example, an application might have functions named foo, bar etc.
which are causing malloc and out of which function ''foo'' might
be
causing a heavy load by calling malloc in a loop with small chunk of
data instead of making a single malloc call with a big chunk of data.
<br>
<br>
So, I am interested in knowing the functions in the user application
which are causing malloc so that source code in the user application
can be modified in case of bottleneck.<br>
<br>
Thanks,<br>
Ashu.<br>
<br>
Adam Leventhal wrote:<br>
<blockquote cite="mid20051206231813.GJ26678@eng.sun.com"
type="cite">
<pre wrap="">On Wed, Dec 07, 2005 at 02:09:56AM +0530,
Ashutosh Kumar wrote:
</pre>
<blockquote type="cite">
<pre wrap="">What a Dscript look like to know which all
functions in user land are
causing malloc?
</pre>
</blockquote>
<pre wrap=""><!---->
How about this:
# dtrace -n pid<pid>::malloc:entry''{ @[ustack(2)] = count();
}''
dtrace: description ''pid167267::malloc:entry'' matched 2 probes
^C
...
libc.so.1`malloc
libmozjs.so`JS_malloc+0x24
7341
libc.so.1`malloc
libCrun.so.1`__1c2n6FI_pv_+0x28
62251
Adam
</pre>
</blockquote>
<br>
<pre class="moz-signature" cols="72">--
Nothing is impossible, except ''impossible'' itself.
-ashu
                                
</pre>
</body>
</html>
Hi Ashu, Ashutosh Kumar wrote:> Thanks Adam, > > I am interested in knowing which functions in the user application are > causing this malloc?This is exactly what ustack() gives you - the user mode call stack. You might want the entire stack. So use ustack() instead of ustack(2). As mentioned by Adam, the script dtrace -n pid<pid>::malloc:entry''{ @[ustack()] = count(); }'' will give you all the different places/ways your application calls malloc and the number of times for each case. Remember, the script uses an aggregation. So you will see the output only when you stop the script (^C). Here is a sample session, dtracing xemacs. ---------- $ dtrace -n pid963::malloc:entry''{ @[ustack()] = count(); }'' dtrace: description ''pid963::malloc:entry'' matched 33 probes ^C xemacs-21.4.16`malloc xemacs-21.4.16`xrealloc+0x40 xemacs-21.4.16`Dynarr_resize+0x90 xemacs-21.4.16`x_output_display_block+0x974 ... xemacs-21.4.16`Feval+0x12e0 1 xemacs-21.4.16`malloc xemacs-21.4.16`calloc+0x10 xemacs-21.4.16`xmalloc_and_zero+0x8 ... xemacs-21.4.16`execute_optimized_program+0x9fc xemacs-21.4.16`Fbyte_code+0xd8 1 ---------- Hope this helps. Cheers Manoj
Thanks Manoj. >Remember, the script uses an aggregation. So you will see the output only when you stop the script (^C). Does that mean, if I use profile-5s or tick-5s I won''t be getting output at a regular interval of 5 sec? Regards, Ashu Manoj Joseph wrote:> Hi Ashu, > > Ashutosh Kumar wrote: > >> Thanks Adam, >> >> I am interested in knowing which functions in the user application >> are causing this malloc? > > This is exactly what ustack() gives you - the user mode call stack. > You might want the entire stack. So use ustack() instead of ustack(2). > > As mentioned by Adam, the script > dtrace -n pid<pid>::malloc:entry''{ @[ustack()] = count(); }'' > > will give you all the different places/ways your application calls > malloc and the number of times for each case. > > Remember, the script uses an aggregation. So you will see the output > only when you stop the script (^C). > > Here is a sample session, dtracing xemacs. > > ---------- > $ dtrace -n pid963::malloc:entry''{ @[ustack()] = count(); }'' > dtrace: description ''pid963::malloc:entry'' matched 33 probes > ^C > > xemacs-21.4.16`malloc > xemacs-21.4.16`xrealloc+0x40 > xemacs-21.4.16`Dynarr_resize+0x90 > xemacs-21.4.16`x_output_display_block+0x974 > ... > xemacs-21.4.16`Feval+0x12e0 > 1 > > xemacs-21.4.16`malloc > xemacs-21.4.16`calloc+0x10 > xemacs-21.4.16`xmalloc_and_zero+0x8 > ... > xemacs-21.4.16`execute_optimized_program+0x9fc > xemacs-21.4.16`Fbyte_code+0xd8 > 1 > > ---------- > > Hope this helps. > > Cheers > Manoj > _______________________________________________ > dtrace-discuss mailing list > dtrace-discuss at opensolaris.org-- Nothing is impossible, except ''impossible'' itself. -ashu
Ashutosh Kumar wrote:> > Thanks Manoj. > > >Remember, the script uses an aggregation. So you will see the output > only when you stop the script (^C). > > Does that mean, if I use profile-5s or tick-5s I won''t be getting output > at a regular interval of 5 sec?of course you will - but you''ll have to explicitly call ''printa()'' :-) (you may want to clear() or trunc() the aggregation after printing them). HTH Michael> Regards, > Ashu > > Manoj Joseph wrote: > > > Hi Ashu, > > > > Ashutosh Kumar wrote: > > > >> Thanks Adam, > >> > >> I am interested in knowing which functions in the user application > >> are causing this malloc? > > > > This is exactly what ustack() gives you - the user mode call stack. > > You might want the entire stack. So use ustack() instead of ustack(2). > > > > As mentioned by Adam, the script > > dtrace -n pid<pid>::malloc:entry''{ @[ustack()] = count(); }'' > > > > will give you all the different places/ways your application calls > > malloc and the number of times for each case. > > > > Remember, the script uses an aggregation. So you will see the output > > only when you stop the script (^C). > > > > Here is a sample session, dtracing xemacs. > > > > ---------- > > $ dtrace -n pid963::malloc:entry''{ @[ustack()] = count(); }'' > > dtrace: description ''pid963::malloc:entry'' matched 33 probes > > ^C > > > > xemacs-21.4.16`malloc > > xemacs-21.4.16`xrealloc+0x40 > > xemacs-21.4.16`Dynarr_resize+0x90 > > xemacs-21.4.16`x_output_display_block+0x974 > > ... > > xemacs-21.4.16`Feval+0x12e0 > > 1 > > > > xemacs-21.4.16`malloc > > xemacs-21.4.16`calloc+0x10 > > xemacs-21.4.16`xmalloc_and_zero+0x8 > > ... > > xemacs-21.4.16`execute_optimized_program+0x9fc > > xemacs-21.4.16`Fbyte_code+0xd8 > > 1 > > > > ---------- > > > > Hope this helps. > > > > Cheers > > Manoj > > _______________________________________________ > > dtrace-discuss mailing list > > dtrace-discuss at opensolaris.org > > -- > Nothing is impossible, except ''impossible'' itself. > -ashu > > > _______________________________________________ > dtrace-discuss mailing list > dtrace-discuss at opensolaris.org-- Michael Schuster (+49 89) 46008-2974 / x62974 visit the online support center: http://www.sun.com/osc/ Recursion, n.: see ''Recursion''
Roch Bourbonnais - Performance Engineering
2005-Dec-07 09:33 UTC
[dtrace-discuss] Source of malloc.
You may also want to check the Heap Profiling capability of Sun Studio Performance Tools (collect -H on a.out; analyzer test.x.er). http://developer.sun.com/sunstudio/download http://www.sun.com/software/products/studio/index.xml -r I am interested in knowing which functions in the user application are causing this malloc? For example, an application might have functions named foo, bar etc. which are causing malloc and out of which function ''foo'' might be causing a heavy load by calling malloc in a loop with small chunk of data instead of making a single malloc call with a big chunk of data. So, I am interested in knowing the functions in the user application which are causing malloc so that source code in the user application can be modified in case of bottleneck. Thanks, Ashu.
Ashutosh Kumar wrote:> Thanks Manoj. > > >Remember, the script uses an aggregation. So you will see the output > only when you stop the script (^C). > > Does that mean, if I use profile-5s or tick-5s I won''t be getting output > at a regular interval of 5 sec?Short answer: if you want some data to be output everytime the probe fires, do a trace() or printf() (or ustack() or stack()...). Don''t use an aggregate! Long answer: It depends on whether or not you use an aggregation in the profile/tick probe. It works this way. If you use an aggregation, then the default action of printing out the function name (probe func) does not happen. The data gathered goes into the aggregation, so to speak. By the way that is the point of using the aggregation. You used it when (and only when) you do *not* want the data printed out everytime the probe fires. You use it to gather data and get the _aggregate_ - sum/count/minimum/maximum etc... If this is not the behaviour you want, and say, you want the user mode stack to be printed when ever malloc is called, you would do this. dtrace -n pid<pid>::malloc:entry''{ ustack(); }'' You will see very quickly that you often end up with lots of repeating data. Try it out on an application that does a lot of mallocs... Hope this helps! Manoj
An alternative way to answer the question is with the Analyzer. collect -H on <target> <args> will collect a heaptrace experiment. Analyzer will show you the leaks, aggregated by common callstack, and the allocations, aggregated by common callstack. It also allow you to navigate to source, disassembly, etc. Marty Jarod Jenson wrote On 12/06/05 16:42,:> > Adam Leventhal''s email at 12/6/2005 5:18 PM, said: > >>On Wed, Dec 07, 2005 at 02:09:56AM +0530, Ashutosh Kumar wrote: >> >> >>>What a Dscript look like to know which all functions in user land are >>>causing malloc? >> >> >>How about this: >> >># dtrace -n pid<pid>::malloc:entry''{ @[ustack(2)] = count(); }'' >>dtrace: description ''pid167267::malloc:entry'' matched 2 probes >>^C >>... >> libc.so.1`malloc >> libmozjs.so`JS_malloc+0x24 >> 7341 >> >> libc.so.1`malloc >> libCrun.so.1`__1c2n6FI_pv_+0x28 >> 62251 >> > > > This here is why I generally go ustack(4). Demangling this to "new" isn''t > terribly helpful. In the case of C++ constructors and new(), ustack(4) usually > gives good success in getting the caller you are interested in without too much > fluff in a deep stack to make for an unmanageable number of stacks that all are > really the same allocation point. > > Thanks, > > Jarod > > _______________________________________________ > dtrace-discuss mailing list > dtrace-discuss at opensolaris.org
I allocations in small chunks turns out to be a problem, an good option could be to use libumem''s slab allocation feature to create pools of small chunks. ckl On Dec 6, 2005, at 9:33 PM, Ashutosh Kumar wrote:> Thanks Adam, > > I am interested in knowing which functions in the user application > are causing this malloc? > > For example, an application might have functions named foo, bar > etc. which are causing malloc and out of which function ''foo'' might > be causing a heavy load by calling malloc in a loop with small > chunk of data instead of making a single malloc call with a big > chunk of data. > > So, I am interested in knowing the functions in the user > application which are causing malloc so that source code in the > user application can be modified in case of bottleneck. > > Thanks, > Ashu. > > Adam Leventhal wrote: >> On Wed, Dec 07, 2005 at 02:09:56AM +0530, Ashutosh Kumar wrote: >>> What a Dscript look like to know which all functions in user land >>> are causing malloc? >> How about this: # dtrace -n pid::malloc:entry''{ @[ustack(2)] = >> count(); }'' dtrace: description ''pid167267::malloc:entry'' matched >> 2 probes ^C ... libc.so.1`malloc libmozjs.so`JS_malloc+0x24 7341 >> libc.so.1`malloc libCrun.so.1`__1c2n6FI_pv_+0x28 62251 Adam > > -- Nothing is impossible, except ''impossible'' itself. -ashu > _______________________________________________ > dtrace-discuss mailing list > dtrace-discuss at opensolaris.org
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1"
http-equiv="Content-Type">
<title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
Hi,<br>
<br>
Thanks to all of you. Is there any other way in Dtrace besides ustack()
to do it? <br>
<br>
I want to know the top 10 functions in the user application which are
source of malloc, so that I can print the result in the following
manner:<br>
<br>
Function Name
No. of malloc calls
malloc''ed amount(bytes)<br>
----------------
-------------------
------------------------<br>
foo
15
15360
<br>
bar
20
20480<br>
......<br>
......<br>
<br>
Using ustack, I need to do a lot of post-processing. <br>
Is there any other method, so that minimal post-processing is
required.<br>
<br>
Thanks,<br>
Ashu.<br>
<br>
Adam Leventhal wrote:
<blockquote cite="mid20051206231813.GJ26678@eng.sun.com"
type="cite">
<pre wrap="">On Wed, Dec 07, 2005 at 02:09:56AM +0530,
Ashutosh Kumar wrote:
</pre>
<blockquote type="cite">
<pre wrap="">What a Dscript look like to know which all
functions in user land are
causing malloc?
</pre>
</blockquote>
<pre wrap=""><!---->
How about this:
# dtrace -n pid<pid>::malloc:entry''{ @[ustack(2)] = count();
}''
dtrace: description ''pid167267::malloc:entry'' matched 2 probes
^C
...
libc.so.1`malloc
libmozjs.so`JS_malloc+0x24
7341
libc.so.1`malloc
libCrun.so.1`__1c2n6FI_pv_+0x28
62251
Adam
</pre>
</blockquote>
<br>
<pre class="moz-signature" cols="72">--
Nothing is impossible, except ''impossible'' itself.
-ashu
                                
</pre>
</body>
</html>
If you''re on a recent build of OpenSolaris or Solaris Express, you
could
use the ucaller variable and the %A format character:
---8<--- whomalloc.d ---8<---
#!/usr/sbin/dtrace -s
#pragma D option quiet
pid$target::malloc:entry
{
@[ucaller] = count();
}
END
{
printa("%-50A %@u\n", @);
}
---8<--- whomalloc.d ---8<---
# ./malloc.d -p `pgrep -n mozilla`
^C
libjsd.so`jsd_alloc_script_entry+0x17 1
libxpcom.so`PL_DHashAllocTable+0x18 1
...
libc.so.1`calloc+0x49 983
libglib-2.0.so.0.400.1`standard_malloc+0xc 11628
libCrun.so.1`__1c2n6FI_pv_+0x33 13760
But, as has been noted, with ustack() you have a considderably better view
into the actual caller in your own application rather than, say, libc''s
calloc() calling malloc() as an implementation detail.
Adam
On Thu, Dec 08, 2005 at 09:11:49PM +0530, Ashutosh Kumar
wrote:> <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01
Transitional//EN">
> <html>
> <head>
> <meta content="text/html;charset=ISO-8859-1"
http-equiv="Content-Type">
> <title></title>
> </head>
> <body bgcolor="#ffffff" text="#000000">
> Hi,<br>
> <br>
> Thanks to all of you. Is there any other way in Dtrace besides ustack()
> to do it? <br>
> <br>
> I want to know the top 10 functions in the user application which are
> source of malloc, so that I can print the result in the following
> manner:<br>
> <br>
> Function Name
No. of malloc
calls
>
malloc''ed amount(bytes)<br>
> ----------------
-------------------
>
------------------------<br>
> foo
15
>
15360
<br>
> bar
20
>
20480<br>
> ......<br>
> ......<br>
> <br>
> Using ustack, I need to do a lot of post-processing. <br>
> Is there any other method, so that minimal post-processing is
required.<br>
> <br>
> Thanks,<br>
> Ashu.<br>
> <br>
> Adam Leventhal wrote:
> <blockquote cite="mid20051206231813.GJ26678 at eng.sun.com"
type="cite">
> <pre wrap="">On Wed, Dec 07, 2005 at 02:09:56AM +0530,
Ashutosh Kumar wrote:
> </pre>
> <blockquote type="cite">
> <pre wrap="">What a Dscript look like to know which all
functions in user land are
> causing malloc?
> </pre>
> </blockquote>
> <pre wrap=""><!---->
> How about this:
>
> # dtrace -n pid<pid>::malloc:entry''{ @[ustack(2)] =
count(); }''
> dtrace: description ''pid167267::malloc:entry'' matched 2
probes
> ^C
> ...
> libc.so.1`malloc
> libmozjs.so`JS_malloc+0x24
> 7341
>
> libc.so.1`malloc
> libCrun.so.1`__1c2n6FI_pv_+0x28
> 62251
>
> Adam
>
> </pre>
> </blockquote>
> <br>
> <pre class="moz-signature" cols="72">--
> Nothing is impossible, except ''impossible'' itself.
> -ashu
>
> </pre>
> </body>
> </html>
--
Adam Leventhal, Solaris Kernel Development http://blogs.sun.com/ahl
Adam, Besides ucaller, do we have kcaller for kernel-land in the recent build? THX. Adam Leventhal wrote On 12/08/05 07:59,:> If you''re on a recent build of OpenSolaris or Solaris Express, you could > use the ucaller variable and the %A format character: > > ---8<--- whomalloc.d ---8<--- > > #!/usr/sbin/dtrace -s > > #pragma D option quiet > > pid$target::malloc:entry > { > @[ucaller] = count(); > } > > END > { > printa("%-50A %@u\n", @); > } > > ---8<--- whomalloc.d ---8<--- > > # ./malloc.d -p `pgrep -n mozilla` > ^C > libjsd.so`jsd_alloc_script_entry+0x17 1 > libxpcom.so`PL_DHashAllocTable+0x18 1 > ... > libc.so.1`calloc+0x49 983 > libglib-2.0.so.0.400.1`standard_malloc+0xc 11628 > libCrun.so.1`__1c2n6FI_pv_+0x33 13760 > > But, as has been noted, with ustack() you have a considderably better view > into the actual caller in your own application rather than, say, libc''s > calloc() calling malloc() as an implementation detail. > > Adam > > On Thu, Dec 08, 2005 at 09:11:49PM +0530, Ashutosh Kumar wrote: > >><!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> >><html> >><head> >> <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type"> >> <title></title> >></head> >><body bgcolor="#ffffff" text="#000000"> >>Hi,<br> >><br> >>Thanks to all of you. Is there any other way in Dtrace besides ustack() >>to do it? <br> >><br> >>I want to know the top 10 functions in the user application which are >>source of malloc, so that I can print the result in the following >>manner:<br> >><br> >>Function Name No. of malloc calls >> malloc''ed amount(bytes)<br> >>---------------- ------------------- >> ------------------------<br> >>foo 15 >> 15360 <br> >>bar 20 >> 20480<br> >>......<br> >>......<br> >><br> >>Using ustack, I need to do a lot of post-processing. <br> >>Is there any other method, so that minimal post-processing is required.<br> >><br> >>Thanks,<br> >>Ashu.<br> >><br> >>Adam Leventhal wrote: >><blockquote cite="mid20051206231813.GJ26678 at eng.sun.com" type="cite"> >> <pre wrap="">On Wed, Dec 07, 2005 at 02:09:56AM +0530, Ashutosh Kumar wrote: >> </pre> >> <blockquote type="cite"> >> <pre wrap="">What a Dscript look like to know which all functions in user land are >>causing malloc? >> </pre> >> </blockquote> >> <pre wrap=""><!----> >>How about this: >> >># dtrace -n pid<pid>::malloc:entry''{ @[ustack(2)] = count(); }'' >>dtrace: description ''pid167267::malloc:entry'' matched 2 probes >>^C >>... >> libc.so.1`malloc >> libmozjs.so`JS_malloc+0x24 >> 7341 >> >> libc.so.1`malloc >> libCrun.so.1`__1c2n6FI_pv_+0x28 >> 62251 >> >>Adam >> >> </pre> >></blockquote> >><br> >><pre class="moz-signature" cols="72">-- >>Nothing is impossible, except ''impossible'' itself. >> -ashu >> >></pre> >></body> >></html> > > >-- ************************************************ * C P Lin, Common Technology Project Lead. * * Sun Microsystems Inc. * * E-Mail: c.lin at sun.com * * Address: 4150 Network Circle, M/S UMPK12-330 * * Santa Clara, CA 95054 * * Phone: 650/352-4967 Fax: 650/786-7816 * ************************************************
Yes. Even in stock Solaris 10 there''s the "caller" variable. Adam On Thu, Dec 08, 2005 at 12:06:18PM -0800, CHIAN-PHON LIN wrote:> Adam, > > Besides ucaller, do we have kcaller for kernel-land in the recent build? > > THX. > > Adam Leventhal wrote On 12/08/05 07:59,: > > If you''re on a recent build of OpenSolaris or Solaris Express, you could > > use the ucaller variable and the %A format character: > > > > ---8<--- whomalloc.d ---8<--- > > > > #!/usr/sbin/dtrace -s > > > > #pragma D option quiet > > > > pid$target::malloc:entry > > { > > @[ucaller] = count(); > > } > > > > END > > { > > printa("%-50A %@u\n", @); > > } > > > > ---8<--- whomalloc.d ---8<--- > > > > # ./malloc.d -p `pgrep -n mozilla` > > ^C > > libjsd.so`jsd_alloc_script_entry+0x17 1 > > libxpcom.so`PL_DHashAllocTable+0x18 1 > > ... > > libc.so.1`calloc+0x49 983 > > libglib-2.0.so.0.400.1`standard_malloc+0xc 11628 > > libCrun.so.1`__1c2n6FI_pv_+0x33 13760 > > > > But, as has been noted, with ustack() you have a considderably better view > > into the actual caller in your own application rather than, say, libc''s > > calloc() calling malloc() as an implementation detail. > > > > Adam > > > > On Thu, Dec 08, 2005 at 09:11:49PM +0530, Ashutosh Kumar wrote: > > > >><!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> > >><html> > >><head> > >> <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type"> > >> <title></title> > >></head> > >><body bgcolor="#ffffff" text="#000000"> > >>Hi,<br> > >><br> > >>Thanks to all of you. Is there any other way in Dtrace besides ustack() > >>to do it? <br> > >><br> > >>I want to know the top 10 functions in the user application which are > >>source of malloc, so that I can print the result in the following > >>manner:<br> > >><br> > >>Function Name No. of malloc calls > >> malloc''ed amount(bytes)<br> > >>---------------- ------------------- > >> ------------------------<br> > >>foo 15 > >> 15360 <br> > >>bar 20 > >> 20480<br> > >>......<br> > >>......<br> > >><br> > >>Using ustack, I need to do a lot of post-processing. <br> > >>Is there any other method, so that minimal post-processing is required.<br> > >><br> > >>Thanks,<br> > >>Ashu.<br> > >><br> > >>Adam Leventhal wrote: > >><blockquote cite="mid20051206231813.GJ26678 at eng.sun.com" type="cite"> > >> <pre wrap="">On Wed, Dec 07, 2005 at 02:09:56AM +0530, Ashutosh Kumar wrote: > >> </pre> > >> <blockquote type="cite"> > >> <pre wrap="">What a Dscript look like to know which all functions in user land are > >>causing malloc? > >> </pre> > >> </blockquote> > >> <pre wrap=""><!----> > >>How about this: > >> > >># dtrace -n pid<pid>::malloc:entry''{ @[ustack(2)] = count(); }'' > >>dtrace: description ''pid167267::malloc:entry'' matched 2 probes > >>^C > >>... > >> libc.so.1`malloc > >> libmozjs.so`JS_malloc+0x24 > >> 7341 > >> > >> libc.so.1`malloc > >> libCrun.so.1`__1c2n6FI_pv_+0x28 > >> 62251 > >> > >>Adam > >> > >> </pre> > >></blockquote> > >><br> > >><pre class="moz-signature" cols="72">-- > >>Nothing is impossible, except ''impossible'' itself. > >> -ashu > >> > >></pre> > >></body> > >></html> > > > > > > > > -- > ************************************************ > * C P Lin, Common Technology Project Lead. * > * Sun Microsystems Inc. * > * E-Mail: c.lin at sun.com * > * Address: 4150 Network Circle, M/S UMPK12-330 * > * Santa Clara, CA 95054 * > * Phone: 650/352-4967 Fax: 650/786-7816 * > ************************************************-- Adam Leventhal, Solaris Kernel Development http://blogs.sun.com/ahl
Adam, Variable caller is type uintptr_t. What is the type of variable ucaller? THX. Adam Leventhal wrote On 12/08/05 13:21,:> Yes. Even in stock Solaris 10 there''s the "caller" variable. > > Adam > > On Thu, Dec 08, 2005 at 12:06:18PM -0800, CHIAN-PHON LIN wrote: > >>Adam, >> >>Besides ucaller, do we have kcaller for kernel-land in the recent build? >> >>THX. >> >>Adam Leventhal wrote On 12/08/05 07:59,: >> >>>If you''re on a recent build of OpenSolaris or Solaris Express, you could >>>use the ucaller variable and the %A format character: >>> >>>---8<--- whomalloc.d ---8<--- >>> >>>#!/usr/sbin/dtrace -s >>> >>>#pragma D option quiet >>> >>>pid$target::malloc:entry >>>{ >>> @[ucaller] = count(); >>>} >>> >>>END >>>{ >>> printa("%-50A %@u\n", @); >>>} >>> >>>---8<--- whomalloc.d ---8<--- >>> >>># ./malloc.d -p `pgrep -n mozilla` >>>^C >>>libjsd.so`jsd_alloc_script_entry+0x17 1 >>>libxpcom.so`PL_DHashAllocTable+0x18 1 >>>... >>>libc.so.1`calloc+0x49 983 >>>libglib-2.0.so.0.400.1`standard_malloc+0xc 11628 >>>libCrun.so.1`__1c2n6FI_pv_+0x33 13760 >>> >>>But, as has been noted, with ustack() you have a considderably better view >>>into the actual caller in your own application rather than, say, libc''s >>>calloc() calling malloc() as an implementation detail. >>> >>>Adam >>> >>>On Thu, Dec 08, 2005 at 09:11:49PM +0530, Ashutosh Kumar wrote: >>> >>> >>>><!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> >>>><html> >>>><head> >>>> <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type"> >>>> <title></title> >>>></head> >>>><body bgcolor="#ffffff" text="#000000"> >>>>Hi,<br> >>>><br> >>>>Thanks to all of you. Is there any other way in Dtrace besides ustack() >>>>to do it? <br> >>>><br> >>>>I want to know the top 10 functions in the user application which are >>>>source of malloc, so that I can print the result in the following >>>>manner:<br> >>>><br> >>>>Function Name No. of malloc calls >>>> malloc''ed amount(bytes)<br> >>>>---------------- ------------------- >>>> ------------------------<br> >>>>foo 15 >>>> 15360 <br> >>>>bar 20 >>>> 20480<br> >>>>......<br> >>>>......<br> >>>><br> >>>>Using ustack, I need to do a lot of post-processing. <br> >>>>Is there any other method, so that minimal post-processing is required.<br> >>>><br> >>>>Thanks,<br> >>>>Ashu.<br> >>>><br> >>>>Adam Leventhal wrote: >>>><blockquote cite="mid20051206231813.GJ26678 at eng.sun.com" type="cite"> >>>> <pre wrap="">On Wed, Dec 07, 2005 at 02:09:56AM +0530, Ashutosh Kumar wrote: >>>> </pre> >>>> <blockquote type="cite"> >>>> <pre wrap="">What a Dscript look like to know which all functions in user land are >>>>causing malloc? >>>> </pre> >>>> </blockquote> >>>> <pre wrap=""><!----> >>>>How about this: >>>> >>>># dtrace -n pid<pid>::malloc:entry''{ @[ustack(2)] = count(); }'' >>>>dtrace: description ''pid167267::malloc:entry'' matched 2 probes >>>>^C >>>>... >>>> libc.so.1`malloc >>>> libmozjs.so`JS_malloc+0x24 >>>> 7341 >>>> >>>> libc.so.1`malloc >>>> libCrun.so.1`__1c2n6FI_pv_+0x28 >>>> 62251 >>>> >>>>Adam >>>> >>>> </pre> >>>></blockquote> >>>><br> >>>><pre class="moz-signature" cols="72">-- >>>>Nothing is impossible, except ''impossible'' itself. >>>> -ashu >>>> >>>></pre> >>>></body> >>>></html> >>> >>> >>> >>-- >>************************************************ >>* C P Lin, Common Technology Project Lead. * >>* Sun Microsystems Inc. * >>* E-Mail: c.lin at sun.com * >>* Address: 4150 Network Circle, M/S UMPK12-330 * >>* Santa Clara, CA 95054 * >>* Phone: 650/352-4967 Fax: 650/786-7816 * >>************************************************ > >-- ************************************************ * C P Lin, Common Technology Project Lead. * * Sun Microsystems Inc. * * E-Mail: c.lin at sun.com * * Address: 4150 Network Circle, M/S UMPK12-330 * * Santa Clara, CA 95054 * * Phone: 650/352-4967 Fax: 650/786-7816 * ************************************************
Also a uintptr_t. Adam On Thu, Dec 08, 2005 at 02:14:40PM -0800, CHIAN-PHON LIN wrote:> Adam, > > Variable caller is type uintptr_t. > What is the type of variable ucaller? > > THX. > > Adam Leventhal wrote On 12/08/05 13:21,: > > Yes. Even in stock Solaris 10 there''s the "caller" variable. > > > > Adam > > > > On Thu, Dec 08, 2005 at 12:06:18PM -0800, CHIAN-PHON LIN wrote: > > > >>Adam, > >> > >>Besides ucaller, do we have kcaller for kernel-land in the recent build? > >> > >>THX. > >> > >>Adam Leventhal wrote On 12/08/05 07:59,: > >> > >>>If you''re on a recent build of OpenSolaris or Solaris Express, you could > >>>use the ucaller variable and the %A format character: > >>> > >>>---8<--- whomalloc.d ---8<--- > >>> > >>>#!/usr/sbin/dtrace -s > >>> > >>>#pragma D option quiet > >>> > >>>pid$target::malloc:entry > >>>{ > >>> @[ucaller] = count(); > >>>} > >>> > >>>END > >>>{ > >>> printa("%-50A %@u\n", @); > >>>} > >>> > >>>---8<--- whomalloc.d ---8<--- > >>> > >>># ./malloc.d -p `pgrep -n mozilla` > >>>^C > >>>libjsd.so`jsd_alloc_script_entry+0x17 1 > >>>libxpcom.so`PL_DHashAllocTable+0x18 1 > >>>... > >>>libc.so.1`calloc+0x49 983 > >>>libglib-2.0.so.0.400.1`standard_malloc+0xc 11628 > >>>libCrun.so.1`__1c2n6FI_pv_+0x33 13760 > >>> > >>>But, as has been noted, with ustack() you have a considderably better view > >>>into the actual caller in your own application rather than, say, libc''s > >>>calloc() calling malloc() as an implementation detail. > >>> > >>>Adam > >>> > >>>On Thu, Dec 08, 2005 at 09:11:49PM +0530, Ashutosh Kumar wrote: > >>> > >>> > >>>><!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> > >>>><html> > >>>><head> > >>>> <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type"> > >>>> <title></title> > >>>></head> > >>>><body bgcolor="#ffffff" text="#000000"> > >>>>Hi,<br> > >>>><br> > >>>>Thanks to all of you. Is there any other way in Dtrace besides ustack() > >>>>to do it? <br> > >>>><br> > >>>>I want to know the top 10 functions in the user application which are > >>>>source of malloc, so that I can print the result in the following > >>>>manner:<br> > >>>><br> > >>>>Function Name No. of malloc calls > >>>> malloc''ed amount(bytes)<br> > >>>>---------------- ------------------- > >>>> ------------------------<br> > >>>>foo 15 > >>>> 15360 <br> > >>>>bar 20 > >>>> 20480<br> > >>>>......<br> > >>>>......<br> > >>>><br> > >>>>Using ustack, I need to do a lot of post-processing. <br> > >>>>Is there any other method, so that minimal post-processing is required.<br> > >>>><br> > >>>>Thanks,<br> > >>>>Ashu.<br> > >>>><br> > >>>>Adam Leventhal wrote: > >>>><blockquote cite="mid20051206231813.GJ26678 at eng.sun.com" type="cite"> > >>>> <pre wrap="">On Wed, Dec 07, 2005 at 02:09:56AM +0530, Ashutosh Kumar wrote: > >>>> </pre> > >>>> <blockquote type="cite"> > >>>> <pre wrap="">What a Dscript look like to know which all functions in user land are > >>>>causing malloc? > >>>> </pre> > >>>> </blockquote> > >>>> <pre wrap=""><!----> > >>>>How about this: > >>>> > >>>># dtrace -n pid<pid>::malloc:entry''{ @[ustack(2)] = count(); }'' > >>>>dtrace: description ''pid167267::malloc:entry'' matched 2 probes > >>>>^C > >>>>... > >>>> libc.so.1`malloc > >>>> libmozjs.so`JS_malloc+0x24 > >>>> 7341 > >>>> > >>>> libc.so.1`malloc > >>>> libCrun.so.1`__1c2n6FI_pv_+0x28 > >>>> 62251 > >>>> > >>>>Adam > >>>> > >>>> </pre> > >>>></blockquote> > >>>><br> > >>>><pre class="moz-signature" cols="72">-- > >>>>Nothing is impossible, except ''impossible'' itself. > >>>> -ashu > >>>> > >>>></pre> > >>>></body> > >>>></html> > >>> > >>> > >>> > >>-- > >>************************************************ > >>* C P Lin, Common Technology Project Lead. * > >>* Sun Microsystems Inc. * > >>* E-Mail: c.lin at sun.com * > >>* Address: 4150 Network Circle, M/S UMPK12-330 * > >>* Santa Clara, CA 95054 * > >>* Phone: 650/352-4967 Fax: 650/786-7816 * > >>************************************************ > > > > > > -- > ************************************************ > * C P Lin, Common Technology Project Lead. * > * Sun Microsystems Inc. * > * E-Mail: c.lin at sun.com * > * Address: 4150 Network Circle, M/S UMPK12-330 * > * Santa Clara, CA 95054 * > * Phone: 650/352-4967 Fax: 650/786-7816 * > ************************************************-- Adam Leventhal, Solaris Kernel Development http://blogs.sun.com/ahl
What is the difference between caller and ucaller? THX. Adam Leventhal wrote On 12/08/05 14:16,:> Also a uintptr_t. > > Adam > > On Thu, Dec 08, 2005 at 02:14:40PM -0800, CHIAN-PHON LIN wrote: > >>Adam, >> >>Variable caller is type uintptr_t. >>What is the type of variable ucaller? >> >>THX. >> >>Adam Leventhal wrote On 12/08/05 13:21,: >> >>>Yes. Even in stock Solaris 10 there''s the "caller" variable. >>> >>>Adam >>> >>>On Thu, Dec 08, 2005 at 12:06:18PM -0800, CHIAN-PHON LIN wrote: >>> >>> >>>>Adam, >>>> >>>>Besides ucaller, do we have kcaller for kernel-land in the recent build? >>>> >>>>THX. >>>> >>>>Adam Leventhal wrote On 12/08/05 07:59,: >>>> >>>> >>>>>If you''re on a recent build of OpenSolaris or Solaris Express, you could >>>>>use the ucaller variable and the %A format character: >>>>> >>>>>---8<--- whomalloc.d ---8<--- >>>>> >>>>>#!/usr/sbin/dtrace -s >>>>> >>>>>#pragma D option quiet >>>>> >>>>>pid$target::malloc:entry >>>>>{ >>>>> @[ucaller] = count(); >>>>>} >>>>> >>>>>END >>>>>{ >>>>> printa("%-50A %@u\n", @); >>>>>} >>>>> >>>>>---8<--- whomalloc.d ---8<--- >>>>> >>>>># ./malloc.d -p `pgrep -n mozilla` >>>>>^C >>>>>libjsd.so`jsd_alloc_script_entry+0x17 1 >>>>>libxpcom.so`PL_DHashAllocTable+0x18 1 >>>>>... >>>>>libc.so.1`calloc+0x49 983 >>>>>libglib-2.0.so.0.400.1`standard_malloc+0xc 11628 >>>>>libCrun.so.1`__1c2n6FI_pv_+0x33 13760 >>>>> >>>>>But, as has been noted, with ustack() you have a considderably better view >>>>>into the actual caller in your own application rather than, say, libc''s >>>>>calloc() calling malloc() as an implementation detail. >>>>> >>>>>Adam >>>>> >>>>>On Thu, Dec 08, 2005 at 09:11:49PM +0530, Ashutosh Kumar wrote: >>>>> >>>>> >>>>> >>>>>><!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> >>>>>><html> >>>>>><head> >>>>>><meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type"> >>>>>><title></title> >>>>>></head> >>>>>><body bgcolor="#ffffff" text="#000000"> >>>>>>Hi,<br> >>>>>><br> >>>>>>Thanks to all of you. Is there any other way in Dtrace besides ustack() >>>>>>to do it? <br> >>>>>><br> >>>>>>I want to know the top 10 functions in the user application which are >>>>>>source of malloc, so that I can print the result in the following >>>>>>manner:<br> >>>>>><br> >>>>>>Function Name No. of malloc calls >>>>>> malloc''ed amount(bytes)<br> >>>>>>---------------- ------------------- >>>>>> ------------------------<br> >>>>>>foo 15 >>>>>> 15360 <br> >>>>>>bar 20 >>>>>> 20480<br> >>>>>>......<br> >>>>>>......<br> >>>>>><br> >>>>>>Using ustack, I need to do a lot of post-processing. <br> >>>>>>Is there any other method, so that minimal post-processing is required.<br> >>>>>><br> >>>>>>Thanks,<br> >>>>>>Ashu.<br> >>>>>><br> >>>>>>Adam Leventhal wrote: >>>>>><blockquote cite="mid20051206231813.GJ26678 at eng.sun.com" type="cite"> >>>>>><pre wrap="">On Wed, Dec 07, 2005 at 02:09:56AM +0530, Ashutosh Kumar wrote: >>>>>></pre> >>>>>><blockquote type="cite"> >>>>>> <pre wrap="">What a Dscript look like to know which all functions in user land are >>>>>>causing malloc? >>>>>> </pre> >>>>>></blockquote> >>>>>><pre wrap=""><!----> >>>>>>How about this: >>>>>> >>>>>># dtrace -n pid<pid>::malloc:entry''{ @[ustack(2)] = count(); }'' >>>>>>dtrace: description ''pid167267::malloc:entry'' matched 2 probes >>>>>>^C >>>>>>... >>>>>> libc.so.1`malloc >>>>>> libmozjs.so`JS_malloc+0x24 >>>>>> 7341 >>>>>> >>>>>> libc.so.1`malloc >>>>>> libCrun.so.1`__1c2n6FI_pv_+0x28 >>>>>> 62251 >>>>>> >>>>>>Adam >>>>>> >>>>>></pre> >>>>>></blockquote> >>>>>><br> >>>>>><pre class="moz-signature" cols="72">-- >>>>>>Nothing is impossible, except ''impossible'' itself. >>>>>> -ashu >>>>>> >>>>>></pre> >>>>>></body> >>>>>></html> >>>>> >>>>> >>>>> >>>>-- >>>>************************************************ >>>>* C P Lin, Common Technology Project Lead. * >>>>* Sun Microsystems Inc. * >>>>* E-Mail: c.lin at sun.com * >>>>* Address: 4150 Network Circle, M/S UMPK12-330 * >>>>* Santa Clara, CA 95054 * >>>>* Phone: 650/352-4967 Fax: 650/786-7816 * >>>>************************************************ >>> >>> >>-- >>************************************************ >>* C P Lin, Common Technology Project Lead. * >>* Sun Microsystems Inc. * >>* E-Mail: c.lin at sun.com * >>* Address: 4150 Network Circle, M/S UMPK12-330 * >>* Santa Clara, CA 95054 * >>* Phone: 650/352-4967 Fax: 650/786-7816 * >>************************************************ > >-- ************************************************ * C P Lin, Common Technology Project Lead. * * Sun Microsystems Inc. * * E-Mail: c.lin at sun.com * * Address: 4150 Network Circle, M/S UMPK12-330 * * Santa Clara, CA 95054 * * Phone: 650/352-4967 Fax: 650/786-7816 * ************************************************