[dtrace-discuss] How to limits stack frames in pid provider with ustack?

Bryan Cantrill
Thu, 21 Jul 2005 17:24:54 -0000

On Thu, Jul 21, 2005 at 12:43:53PM -0400, Brian Utterback
wrote:
> I am trying to implement a call analyzing graph tool, and I am
> trying to get dtrace to capture counts of caller-callee pairs.
> My thought on this was to use an aggregate for this, indexing by
> the output of ustack. I though to limit the stack frames to only
> 2, but for some reason, dtrace doesn''t like it when I add the
> frame limit:
>
> # dtrace -n pid6886::gettimeofday:entry''{ustack();}''
> dtrace: description ''pid6886::gettimeofday:entry'' matched
3 probes
> CPU     ID                    FUNCTION:NAME
>   1  44286               gettimeofday:entry
>               libc.so.1`gettimeofday
>               libumem.so.1`umem_update_thread+0x1e4
>               libc.so.1`_lwp_start
> ^C
>
> #dtrace -n pid6886::gettimeofday:entry''{ustack(2);}''
> dtrace: invalid probe specifier pid6886::gettimeofday:entry: extraneous
> argument ''{ustack(2);}'' ($1 is not referenced)

Are you absolutely sure there wasn''t a space between the entry and the
tick in the above?  This works for me on both S10/GA and Nevada/latest:

  # dtrace -n BEGIN''{ustack(2)}''
  dtrace: description ''BEGIN'' matched 1 probe
  CPU     ID                    FUNCTION:NAME
    1      1                           :BEGIN
                  libc.so.1`ioctl+0xa
                  libdtrace.so.1`dtrace_go+0xef
  ^C

But the following will _always_ generate the message that you saw:

  # dtrace -n BEGIN ''{ustack(2)}''
  dtrace: invalid probe specifier BEGIN: extraneous argument
''{ustack(2)}''
  ($1 is not referenced)

You can naturally see why; dtrace(1M) can''t differentiate that clause
from
an argument (one could argue that we could have a slightly better message
when the extraneous argument looks suspiciously like a valid D clause,
but it''s an error at any rate).

Anyway, verify that there wasn''t a space -- and if it''s still
busted,
please let us know what bits you''re running on...

	- Bryan

--------------------------------------------------------------------------
Bryan Cantrill, Solaris Kernel Development.       http://blogs.sun.com/bmc