Re: [dtrace-discuss] Can't print stack traces if printa has a format string?
Ryan Johnson wrote: Is there a way to print stack traces as part of an aggregation key in dtrace? I'm trying to count occurrences of different stack traces, but my program has lots of indirect function calls and the output of stack() often doesn't contain the current function. Aggregating on @who[caller,stack()] should fix this in theory, but I can't get the printing to work right. Ah! Turns out this question was already asked in 2005, and the answer is "%k" On a related note, it seems that "%A" can translate user-level addresses to symbols in a printf/printa, which is not documented AFAICT and has caused me pain in the past (see http://kr.sun.com/developers/solaris/techdocs/dtrace_tips_public.pdf) I've updated the printf/printa wiki page to mention both %A and %k. Ryan ___ dtrace-discuss mailing list dtrace-discuss@opensolaris.org
[dtrace-discuss] Can't print stack traces if printa has a format string?
Hi all,
Is there a way to print stack traces as part of an aggregation key in
dtrace? I'm trying to count occurrences of different stack traces, but
my program has lots of indirect function calls and the output of stack()
often doesn't contain the current function. Aggregating on
@who[caller,stack()] should fix this in theory, but I can't get the
printing to work right.
printa(@who) shows the stack but just an address for caller, and neither
%a nor %s allows me to print a stack trace if I give printa a format string:
printa("%40a %40s %...@d", @who)
dtrace: failed to compile script who.d: line 30: printa( ) argument #3
is incompatible with conversion #2 prototype:
conversion: %s
prototype: char [] or string (or use stringof)
argument: stack
printa("%40a %40a %...@d", @who)
dtrace: failed to compile script who.d: line 30: printa( ) argument #3
is incompatible with conversion #2 prototype:
conversion: %a
prototype: pointer or integer
argument: stack
On a related note, it seems that "%A" can translate user-level addresses
to symbols in a printf/printa, which is not documented AFAICT and has
caused me pain in the past (see
http://kr.sun.com/developers/solaris/techdocs/dtrace_tips_public.pdf)
Ideas?
Ryan
___
dtrace-discuss mailing list
dtrace-discuss@opensolaris.org
Re: [dtrace-discuss] what is feeding recvfrom()
> > I tried dtrace to capture the difference as following:
> > #!/usr/sbin/dtrace -qs
> > proc:::signal-send
> > /args[2] == SIGPIPE/
> > {
> > printf ( "SIGPIPE was sent by %s pid = %d \n",
> > args[1]->pr_fname,args[1]->pr_pid);
> > }
> >
> > This doesn't work as SIGPIPE is not a signal. Could anyone suggest the right
> > approach?
> >
> > Thanks in advance,
> >
Not sure what you mean by "SIGPIPE is not a signal", but you might
want to investigate "proc::psig:signal-handle".
Rennie
___
dtrace-discuss mailing list
dtrace-discuss@opensolaris.org
Re: [dtrace-discuss] track program time - need some guidelines
Thanks Jim. > Threads are put to sleep when they issue blocking > system calls. > I'm not sure exactly what you mean by "only know > synchronous > app wait from an app perspective", but the > threads will be in the > sleep state (SLP) after issuing the read/write until > the data is > available, at which point a wakeup is issued and the > thread goes to > runnable. I wanted to avoid any filesystem specifc behavior from the output. > You're conspicuously avoiding answering the "what > problem are you > trying to solve question", which has been asked > multiple times. I hoped I tried to convey that couple of times, I guess I am not clear enough. Sorry about that. The problem remains the same: profile app run time. sys, usr, various wait's. From your reponse, it becomes clear that think I have been using the wrong term, instead of calling wait's that time is sleep. So, a breakup of sleep time among various reasons. > This is no longer a DTrace question, so any further > queries should get > posted to the performance forum. > OK. CC'd to "Communities-performance-discuss" -- This message posted from opensolaris.org ___ dtrace-discuss mailing list dtrace-discuss@opensolaris.org
Re: [dtrace-discuss] track program time - need some guidelines
Threads are put to sleep when they issue blocking system calls. I'm not sure exactly what you mean by "only know synchronous app wait from an app perspective", but the threads will be in the sleep state (SLP) after issuing the read/write until the data is available, at which point a wakeup is issued and the thread goes to runnable. You're conspicuously avoiding answering the "what problem are you trying to solve question", which has been asked multiple times. This is no longer a DTrace question, so any further queries should get posted to the performance forum. /jim tester wrote: Thanks everyone. A quick question, where would be the time be accounted for a thread that wait for a write/read syscall to a block device? I would only like to know the synchronous app wait from an app perspective irrespective of all the async activities that supports it. I havn't looked at Sun studio yet since I don't think I can install it our env. Time for me go and re-read the thread again,I guess. Thanks again. ___ dtrace-discuss mailing list dtrace-discuss@opensolaris.org
Re: [dtrace-discuss] track program time - need some guidelines
Thanks everyone. A quick question, where would be the time be accounted for a thread that wait for a write/read syscall to a block device? I would only like to know the synchronous app wait from an app perspective irrespective of all the async activities that supports it. I havn't looked at Sun studio yet since I don't think I can install it our env. Time for me go and re-read the thread again,I guess. Thanks again. -- This message posted from opensolaris.org ___ dtrace-discuss mailing list dtrace-discuss@opensolaris.org
