similar to: USDT probes in both static library and application

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

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

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

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%

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

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

[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

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

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

Hi, Is there a specific reason the DTRACEHIOC_REMOVE ioctl is deprecated? I found I needed to use it in my Perl USDT provider code[*], which creates providers dynamically at runtime. I wonder if I''m missing a better way of doing the same thing. The situation I''m handling with the remove operation is killing and recreating a perl interpreter in the same process, which

Hi, I''m working on some performance analysis with our database and it seems that when the file system (UFS) is mounted with forcedirectio, the IO probe are not triggered when an I/O event occurs. Could you confirm that ? If so, why ? Seb -- This message posted from opensolaris.org

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

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

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 hi, i''m trying to use the nfsv3 provider on S10U6, with the following simple script: #! /usr/sbin/dtrace -s #pragma D option quiet nfsv3:::op-read-start { printf("%s\n", args[1]->noi_curpath); } however, when running it, i get the following error: dtrace: failed to compile script ./nfs2.d: line 5: failed to grab

I was looking at mod_trace (http://prefetch.net/projects/apache_modtrace/index.html ) and playing with getting it to compile on OS X. When building for x86_64 with -arch x86_64 we get bad instructions generated: gcc -o foo -arch x86_64 foo.c /var/folders/rV/rV1x2DafFr0R6tGG+1bbk++++TM/-Tmp-//ccnykQ1o.s:11:bad register name `%%esi)'' Using gcc -S I can definitely see we are not

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.

Hi, I was going through the implementation of the fasttrap provider. I found that when displaced execution happens (ie., when the instruction traced is being executed out of the scratch space) if an asynchrnous signal comes we need to defer the delivery. Can somebody explain why this is necessary and how is it implemented? Thanks in advance Saravanan S -------------- next part -------------- An

I''ve found what I think is a deadlock in the dtrace fork code. My only Solaris test machine is a single cpu box, where I have been unable to reproduce in the field so far. I''ve been able to reproduce on other platforms. Here is the scenario. You''ve got a target process, which has static probes. It is calling fork(), which causes it to end up at line 330 in fork.c:

I have added a specification of probes for the fibre channel COMSTAR port provider to the DTrace section of wikis.sun.com. The proposal may be found here: http://wikis.sun.com/display/DTrace/fibre+channel+Provider I welcome feedback regarding this proposal. Thanks, Sam