similar to: USDT probe issues in C++

I have a test program which has a call sequence of a(), b(), c(), d(). When I place a pid return probe on d(), I get a ustack that looks like this: a.out`d+0x19 a.out`b+0xd a.out`a+0xd a.out`main+0x3c a.out`_start+0x7a The c() method appears to be missing. I did some poking around and noticed that pid return probes

I am trying to integrate John Levon''s ustack() helper for Python into the upstream Python sources. The method for doing this on Solaris is to compile the phelper.d script containing the helper into an object file using "dtrace -G". dtrace on OS X does not have "dtrace -G", just "dtrace -h". This works fine for USDT probes, but I am at a loss on how to

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

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

[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

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

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

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

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?

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

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%

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 wrote a simple c programme and do some dtrace test. the progromme shows below(write.c): /////////////////////////////// #include<stdio.h> #include <sys/types.h> #include <sys/stat.h> #include <fcntl.h> char *value="hello,my name is wanjm\n"; void main() { int fd; fd=open("/export/home/wanjm/temp/read.txt",O_RDWR|O_CREAT); while(1) {

I have a funny issue whereby when a application exits the proc:::exit probe doesn''t seem to be firing. A customer has written a dtrace script that outputs some info whenever proc:::exit fires but on occasion (random, no pattern in behaviour) dtrace exits without outputting the data. They are running dtrace via ''dtrace -s exit_trace.d -p <pid>'' Can anyone think

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

hi, I am trying to find out the avg cpu time spent in each of my user methods (exclusive of other methods invoked by a method). Hence the following snippet failed miserably: ----------------------- pid$target:a.out::entry { time[probefunc] = timestamp;} pid$target:a.out::return { @spent[probefunc] = avg(timestamp - time[probefunc]);} END { printa(@spent);}

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