similar to: putting a running app into trace mode

I added a couple of static probes to Firefox to measure actual work done. I could have used a pid$target probe with a function name but work is done within an if statement, which is where I placed the static probes. I''m wondering about my use, though. Is the following significantly more efficient than pid$target::FunName:entry and return? I heard somewhere that $target does not

What is the hex number after the method, e.g. +0x32f below? It matches arg0 and I suspect it''s the c++ "this" pointer, aka hidden first argument. I would like to confirm, though. Thanks, Joel --- XUL`PresShell::ProcessReflowCommands(int)+0x32f XUL`PresShell::FlushPendingNotifications(mozFlushType) +0x19e

I''m trying to time a function within Firefoxwith a pid$target probe [2]. e.g dtrace -Zqw -x dynvarsize=64m -x evaltime=preinit -p 13954 -s menu- construct.d -s sigcont.d elapsed: 12.7942481ms cpu : 7.7911194ms count : 40 times I''m also measuring Firefox startup time by running it arguments like this: ... file:///Users/joelr/work/mozilla/startup/startup.html#`python

Just to let people know what my big picture is, I''m trying to write a script that will let me run a program, and name a progeny of that program that I want to debug. My script should find the first occurrence of that progeny, and run it until it finishes initializing the runtime linker, but stop it before it runs any shared library startup routines. (Failing that, I''d be okay

everyone, Just out of curiosity, I did a dtrace -n ''syscall:::entry { @num[execname, probefunc] = count(); }'' and looked at the entries produced by ''rm''. I see everything that rm did, *except* the unlinkat - which is unfortunate because I want to trace which processes have deleted which files. So - does dtrace contain unlinkat as a probe for a system call?

Hi All, I''ve got a problem when I have USDT probes in a static library and in the application code outside of the library. I build the static library containing some USDT probes, glomming everything together (ld -r) before creating the .a file to preserve the probe symbols. This all works fine. I build an application which also has some USDT probes. When I build the application which

Hi, I am tracking down a problem and would like to know how I can follow a forked process with my dtrace script, or how I can trace a dynamic library. Here is the problem. I am tracing dtlogin, and specifically I am trying to determine what error libpkcs11`<routine> is returning. It turns out dtlogin forks a lot of processes, and I believe the second forked process is the one that winds

Hi, As I''ve discussed before whenever we add USDT probes to a C++ function and call dtrace -l we get the mangled C++ name for the dtrace function, being listed :( Now the point of USDT probes is to abstract a higher level semantic construct for users to make use of. Surely it is not meant to be listing Unstable Interfaces (implementation details), such as the containing C++

Hi, I''m posting a question hoping someone will know the answer off hand thereby reducing my search time. :-) With USDT probes, the tracepoint is only installed by libdtrace itself, never by the drti ioctl. So whenever I run a program with an USDT probe, no tracepoint is installed. Only after I run the dtrace command the tracepoint is actually installed on the victim process. My question

This came up as an RFE during the conference (I believe it''s been logged as "4012008: brendan() action needed for DTrace Toolkit".) As everyone here is aware, DTrace is not quite as user friendly as it could be. For the uninitiated, it can be confusing to run a DTrace script and not see the expected output. Brendan Gregg has addressed this in the DTrace Toolkit[1] by

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 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

Hi people, When working with some usdt C++ probes we have come across a few issues. Controlling USDT Function name: Putting in usdt probes into C++ code gives you the mangled enclosing function name for the probes Function name. Working around this can be a pain. You need to wrap your usdt probes in extern C functions and call these. Could we have an option to control the Function name for

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:

X.Org has adopted GNU autoconf as its build configuration mechanism, so when I integrated the dtrace probes, I checked to see if they should be built using this test, checking for the existence of a program named "dtrace" in the path: dnl Check for dtrace program (needed to build Xserver dtrace probes) AC_ARG_WITH(dtrace, AS_HELP_STRING([--with-dtrace=PATH], [Enable dtrace

How do I query an application to see if it supports any USDT probe points?

[Perhaps someone could rename this list to dtrace-matt-problems-discuss?] If I run this script against my binary (which contains a USDT probe called ''concurrentq-latency''): ::: / probename == "concurrentq-latency" / { printf("[%s]:[%s]:[%s]\n", probeprov, probefunc, probename); } I get this output: dtrace: script ''testq.d'' matched 46056

Hi all, I am trying to write a D script which would print ustack() for every program in the system receiving SIGSEGV. All the stacks printed in trap()/sigtoproc() context do not have meaningful symbols. The following solves the problem to some degree but I''d much rather have a self-contained D script. dtrace -w -n ''fbt:genunix:sigtoproc:entry/arg2 == 11/ {

Hi, I want to use USDT in my java applications. Please tell me how to achieve this. I am comfortable with SDT in C application. I am using Solaris Sparc10 with Generic_120011-14 version. Do I need to update my machine for this? Thanks, Ajit -- This message posted from opensolaris.org

As of patch 32953 dtrace support is in bleadperl (5.11.0). The probes are based on Alan Burlinson''s original blog post on the subject: http://blogs.sun.com/alanbur/date/20050909 By guarding the probes with PERL_SUB_*_ENABLED the performance hit is unmeasurable. All the necessary bits already existed in the wild. I just assembled them and made the necessary changes to