dtrace discuss - Jul 2007 - Error trying to count return points in functions.

Whilst trying out some D to get an insight into what is the most
common reason for a given function to return, I have bumped
into an error I don''t understand.

The first take on what I was trying to do was:
# dtrace -n ''fbt:ip:ip_input:return{@home[arg0] = count();}''

and all was well.  The next step was:
# dtrace -n ''fbt:ip::return{@home[strjoin(probefunc,(string)arg0)] = 
count();}''

but the output was not quite so friendly:
dtrace: description ''fbt:ip::return'' matched 1653 probes
dtrace: error on enabled probe ID 1574 (ID 23867: 
fbt:ip:ip_loopback_src_or_dst:return): invalid address (0x30) in action 
#2 at DIF offset 48
dtrace: error on enabled probe ID 769 (ID 25479: 
fbt:ip:ilm_lookup_ill:return): invalid address (0x52) in action #2 at 
DIF offset 48
...

and all is not well.  I''ve also tried stringof(arg0) but the result is 
similar.
By way of testing, @home[probefunc] worked fine.

Is this a bug (fixed in nevada?) or am I just not supposed to do this?

Darren

G''Day Darren,

On Tue, Jul 10, 2007 at 06:46:55PM -0700, Darren.Reed at Sun.COM
wrote:
> Whilst trying out some D to get an insight into what is the most
> common reason for a given function to return, I have bumped
> into an error I don''t understand.
> 
> The first take on what I was trying to do was:
> # dtrace -n ''fbt:ip:ip_input:return{@home[arg0] =
count();}''
> 
> and all was well.  The next step was:
> # dtrace -n ''fbt:ip::return{@home[strjoin(probefunc,(string)arg0)]
=
> count();}''
> 
> but the output was not quite so friendly:
> dtrace: description ''fbt:ip::return'' matched 1653 probes
> dtrace: error on enabled probe ID 1574 (ID 23867: 
> fbt:ip:ip_loopback_src_or_dst:return): invalid address (0x30) in action 
> #2 at DIF offset 48
> dtrace: error on enabled probe ID 769 (ID 25479: 
> fbt:ip:ilm_lookup_ill:return): invalid address (0x52) in action #2 at 
> DIF offset 48
> ...
> 
> and all is not well.  I''ve also tried stringof(arg0) but the
result is
> similar.
Both "(string)" and "stringof()" are attempting to
dereference a "char *".
arg0 is a uint. If you wanted to append it to the probefunc using strjoin(),
then you can turn it into a string using lltostr().

A better way may be to make it a 2-key hash,

# dtrace -n ''fbt:ip::return { @[probefunc, arg0] = count(); }
    END { printa("   %32s+%#-8x %@8d\n", @); }''

no worries,

Brendan

-- 
Brendan
[CA, USA]

I know how to access an application''s global variables, but can I also 
access the local variables in an application?

Cheers, Liam
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://mail.opensolaris.org/pipermail/dtrace-discuss/attachments/20070711/2fd48eca/attachment.html>

Brendan Gregg - Sun Microsystems wrote:
>G''Day Darren,
>
>On Tue, Jul 10, 2007 at 06:46:55PM -0700, Darren.Reed at Sun.COM wrote:
>
>>Whilst trying out some D to get an insight into what is the most
>>common reason for a given function to return, I have bumped
>>into an error I don''t understand.
>>
>>The first take on what I was trying to do was:
>># dtrace -n ''fbt:ip:ip_input:return{@home[arg0] =
count();}''
>>
>>and all was well.  The next step was:
>># dtrace -n
''fbt:ip::return{@home[strjoin(probefunc,(string)arg0)] =
>>count();}''
>>
>>but the output was not quite so friendly:
>>dtrace: description ''fbt:ip::return'' matched 1653
probes
>>dtrace: error on enabled probe ID 1574 (ID 23867: 
>>fbt:ip:ip_loopback_src_or_dst:return): invalid address (0x30) in action 
>>#2 at DIF offset 48
>>dtrace: error on enabled probe ID 769 (ID 25479: 
>>fbt:ip:ilm_lookup_ill:return): invalid address (0x52) in action #2 at 
>>DIF offset 48
>>...
>>
>>and all is not well.  I''ve also tried stringof(arg0) but the
result is
>>similar.
>>
>
>Both "(string)" and "stringof()" are attempting to
dereference a "char *".
>arg0 is a uint. If you wanted to append it to the probefunc using strjoin(),
>then you can turn it into a string using lltostr().
>
Yes, the lltostr() fixes the problem.
It would be nice if dtrace knew more about types and could
say that strjoin() was getting an argument that was the wrong
type rather than the above error.
>A better way may be to make it a 2-key hash,
>
># dtrace -n ''fbt:ip::return { @[probefunc, arg0] = count(); }
>    END { printa("   %32s+%#-8x %@8d\n", @); }
>
hmmm, yes, that works too and the END{...} solves the problem of
the default output being too wide for 80 columns.

thanks,
Darren

> I know how to access an application''s global variables, but can I
also
> access the local variables in an application?
It''s rather difficult. You have to figure out how the compiler has
chosen
to store the local variables and then access the appropriate registers
through the uregs[] array or use uregs[] in concert with the copyin()
subroutine if the compiler has chosen to store the local in memory.

Adam

-- 
Adam Leventhal, Solaris Kernel Development       http://blogs.sun.com/ahl

Hi Liam,
> I know how to access an application''s global variables, but can I
also
> access the local variables in an application?
As Adam mentioned in his reply, this isn''t a particularly nice thing
to do really. I''ve put a small example up on my blog which demonstrates
the basic method used to achieve this. You can find it at:

http://blogs.sun.com/jonh/date/20070712

Hope it''s of some use.

Jon.