similar to: Request for code review: the brendan() action

Hi, Searched for similar errors and nothing came up. Anybody know what this is? When using aggregate stddev, and then trying to print it at END, using printa, I get this error: dtrace: processing aborted: Invalid return value from callback avg works fine. Tried on two recent builds of solaris (build 89 and build 94), on two difference sparc systems. Here''s a sample script:

As noted on my blog and at http://www.opensolaris.org/os/community/dtrace/shells/ I''ve made available a DTrace provider for the Bourne shell. Before anyone starts yelling at me for not starting with another shell, read the blog I made explaining why we started with shell (link on the community page referenced above). For /bin/sh, I''ve put up something akin to a chapter in

Suppose I have a USDT probe in Firefox and that I''m trying to catch the startup with a probe like this: proc:::exec-success /execname == "firefox-bin"/ { start = timestamp; } and stop tracing when Firefox hits this USDT probe: mozilla:::main-entry { exit(0); } How do I put the running firefox-bin into "trace mode" so that my USDT probe fires? Thanks, Joel

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

I believe that I have incorporated all of the feedback given (thanks!). Changes since the 2008-11-16 version include: - ksh style & coding standards compliance in test script (Roland) - "dof_init_debug == B_FALSE" vs. "!dof_init_debug" (Adam) The updated webrev is at: http://cr.opensolaris.org/~mgerdts/6750659-2008-12-03/ -- Mike Gerdts http://mgerdts.blogspot.com/

G''Day All, I''m putting together a PSARC case to begin integration of the DTrace network providers. I''ve drawn up a rough plan which splits this project into over a dozen smaller steps, as documented on the network provider page: http://www.opensolaris.org/os/community/dtrace/NetworkProvider#Plan Below is a draft PSARC document for task 1, IP provider send/receive

> There are times when arg0 can be NULL [for the interrupt-start or > interrupt-complete probe] if there''s no associated device. > There''s already a bug open to address the error in the documentation. > 6284911 args to interrupt-start and interrupt-complete need more info Hmm, I noticed that, too. There''s currently a thread on yahoo''s solarisx86

Does anyone out there have any thoughts on the type of load common DTrace scripts would cause on a system if run 24x7? I know "common DTrace scripts" and their underlining probe calls a vague statement. So for the lack of a common and establish set of scripts in the OS, I''ll use the most popular right for my question...the DTraceToolkit from Brendan Gregg. Which by the

Hi, I have a situation where a DTrace script is printing out extra characters, despite the copyin() call giving a specific length. Can anyone think of why this might be? It''s fine the first time all of the probes fire, but on a second run of my generating operations, I get junk in there. For example: set setop length 5, FOUND KEY, STORED set setop length 5, FOUND KEY, STORED get

I recently did a backport of a couple of networking bug fixes from s10x_u4_b6 to s10x_u3_b10. I patched just /platform/i86pc/kernel/unix and /platform/i86pc/kernel/amd64/unix in my existing u3 OS image and I''m seeing this dtrace problem when running any dtrace script: NODE hcb101 ~ $ ./tcpstat.sh dtrace: failed to compile script /dev/fd/10: "/usr/lib/dtrace/procfs.d", line

Hi , I have posted DTrace script to snoop tcp traffic and also provided a wrapper script for it to filter out unwanted traffic. http://blogs.sun.com/roller/comments/raviswam/Weblog/tcp_snoop_using_dtrace Please let me know if you have any feedback/comments on this. Thanks Ravi

I''m interested in monitoring the amount of stack used by a multi-threaded program. I assume ''stackdepth'' built-in would be useful...but not sure. Been through demo''s, ToolKit, and internals..but it''s just not clicking for me yet. Not sure how to measure start/end of stack size dynamically...Anyone know how to break this down? This message posted from

G''Day Folks, While I have a few minutes online (which is rare at the moment - travel), let me post about a couple of new scripts. I''ve just uploaded them to http://www.brendangregg.com/dtrace.html. They are to profile user-level functions and libaries; and kernel-level functions and modules. They sample, rather than trace (which can be both good and bad). Here is hotuser

I see Intel has released a new tool. Oh, it requires some patches to the kernel to record latency times. Good thing people don''t mind patching their kernels, eh? So who can write the equivalent latencytop.d the fastest? ;-) http://www.latencytop.org/ -- cburgess at qnx.com

hi folks we''re in final approach with Brendan''s work on the TCP and UDP providers, which have been discussed here previously in the context of the overall networking provider plan at: http://hub.opensolaris.org/bin/view/Community+Group+dtrace/NetworkProvider The specs have been updated to reflect recent changes and are available for review here:

G''Day Folks, Check out this DTrace script, # ./swapinfo.d RAM _______Total 511 Mb RAM Unusable 8 Mb RAM Kernel 96 Mb RAM Locked 0 Mb RAM Used 318 Mb RAM Avail 88 Mb Disk _______Total 1023 Mb Disk Used 9 Mb Disk Avail 1014 Mb Swap _______Total 1367 Mb Swap Used 327

Is there a trick to listing available providers? I can''t find it.

i''m using the following probe to calculate how many bytes are being written by tcp write calls, by process and total: fbt:ip:tcp_output:entry { this->tcpout_size = msgdsize(args[1]); @tcpout_size[execname] = sum(this->tcpout_size); @tcpout_size["TOTAL_TCP_OUT"] = sum(this->tcpout_size); } I run this probe for N seconds. I suppose that if i get the

Is there any work on keeping DTraceTools up to date with the latest snv builds. These scripts are pretty useful and help get a novice dtrace user like me doing useful work quickly. Specifically the tcp stack tools like tcptop and tcpsnoop don''t work with later OpenSolaris builds. Thanks, Gary -- This message posted from opensolaris.org

I want to list/use the nfs probes but I get the error "dtrace: failed to match nfs*:::: No probe matches description". Is there a way to enable nfs provider probes? My system is running snv_112 (bfu''ed from the gate archive) # dtrace -lP nfs* ID PROVIDER MODULE FUNCTION NAME dtrace: failed to match nfs*:::: No probe matches