similar to: listing USDT probes, if any

Hi, I am adding DTrace probes within NFS v3 client. In my current implementation, I use some tsd_*() functions and kmem_zalloc() function. These functions might be heavy and affect the performance. I want to call this function only when DTrace is running or the DTrace probes are enable. So is there a way to check DTrace is running or DTrace probe is enabled? Regards, Danhua

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''m running Indiana (OpenSolaris developer preview) under parallels in OS X 10.5.1. I can consistently get Solaris to hang. Doing a dtrace -n pid\$target::malloc:entry''{@=count()}'' -c ls will consistently hang Solaris. Basically doing anything with PID provider with the -c option seems to hangs Solaris. Only way to recover is to stop and start Parallels desktop.

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

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

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 all, I remember at OSCON 2005 there was talk of adding DTrace probes to PHP (in fact, I have a photo of Bryan and Wes working on it!). Did they ever get into the upstream branch, ''cause I don''t recall seeing a --enable-dtrace (or similar) configuration option when I recently built PHP 5.2.1. If not, is there an ETA? TIA, -- Rich Teer, SCSA, SCNA, SCSECA, OpenSolaris CAB

Hello, I am trying to get documentation how how this lazyloading happens when you are dealing with dtrace probes being added to user applications. In particular if it somehow avoids the overhead of registering dtrace probes when they aren''t needed, how does it know if they are needed, etc... thanks, Robert

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

Hello, If I release a new kernel module, do I need to release a SDT provider with it? Just like what "mdb" does - a mdb module together with the associated kernel module. Is it a "MUST" or a "OPTION"? Also what''s the requirement of USDT and user application? Is it encouraged or not to have many probes inside the code? Can I define my own

I have inserted some probes in my application, and it works great in the "debug build" I have been using. So I wanted to look at the "overhead" introduced by inactive dtrace probes in my application. I am using the Sun Studio 11 compiler, so I added the following options: -xO5 -g0 -xbuiltin But this breaks the linking of my application. Undefined first

[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

while trying to use the USDT made available to us in Postgresql database I have problems enabling them. On my database server I ran 1024+ PG processes (1024 clients). The server is a 8 core T2000 @1000MHz. 32GB. 7 storage arrays. Solaris 10 Update 4. Home compiled PG 8.3 beta 1 (optimized binary for T1 chip) with DTrace probes enabled. When running without enabling the probes I have approx 25%

I use a lot of tabs and Firefox runs very slowly. I would like to figure out which tabs are eating up resources (cpu, memory, etc). Will the Mozilla dtrace framework be any help with this? -- This message posted from opensolaris.org

Hi, I have mentioned before that we have added some sdt dtrace probes in SAX, our APL interpreter. Encouraged by Angelo and Jignesh, I have created a small document (5 pages) describing our experience with it, together with some problems we have encountered and some scripts we use for pretty-printing dtrace outputs. The said document can be found at

Hi - I''m trying to use plockstat to help identify any mutex contention issues we may have in our c++ app. >From the docs it would appear to be a very useful tool - unfortunately in practice this doesn''t bear out purely because the stack traces produced are limited to being 39/40 characters wide. In general this means that I''m not seeing ~75% of each stack symbol and

Is there a limit on the number of user space probes that can be present at any time? I have compiled very many probes into our product, and can''t see all of them in "dtrace -l". it looks very much like I have all of them up to some point at which I''ve hit some hard limit. I can see a total of 8588 probes, I think 2 processes have all of the ones I expect (one has 1752

Hy! I receive an nxge driver messages on console: Aug 18 11:08:42 [hostname] nxge: NOTICE: nxge_ipp_eccue_valid_check: rd_ptr = XXX wr_ptr = YYY I find the bug description/correction at sun web page, and i know i can ignore it. I thinking about how can i delete from console only these messages (here is my first version, what is not (so) elegant): #!/usr/sbin/dtrace -qs #pragma D option

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

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