similar to: DTrace in Perl: What probes should we have?

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

This is a semantic question. (I''m doing some technical writing about DTrace.) I''ll little confused about how to explain what an "action" is. By any definition, "trace(x);" is an action. However, what about just "i++;"? Looking at the DTrace guide page 76: "Probe actions are described by a list of statements separated by semicolons (;)

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

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

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 cannot seem to probe any of the Python interpreter''s C functions on OS X. $ sudo dtrace -n ''pid$target::PyEval_EvalFrameEx:entry'' -c python dtrace: invalid probe specifier pid$target::PyEval_EvalFrameEx:entry: probe description pid59706::PyEval_EvalFrameEx:entry does not match any probes These functions show up in ustack()s, but they do not appear to be available

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

Howdy, I am attempting to isolate the location of a memory leak in a 4GL program, and have hit a bit of a snag. When I LD_PRELOAD libumem and run the application server, "::findleaks -fdv" reports numerous leaks: CACHE LEAKED BUFCTL CALLER 0000000100b49068 15 0000000100ef2d50 fdcon+0x6c4 0000000100b50028 1 0000000100b72ac0 fdcon+0x6c4 0000000100b49068

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

[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, I need help in calculating Java method time-stamp in following fashion. Consider following method example. long method3(long stop) { try { Thread.sleep(1500); } catch (Exception e) { } //////////////////// real CPU intensive operation /////////////////////////// for (int i = 1; i < stop; i++) { stop = stop * stop * i; };

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

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

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

>From time to time a jboss process would end eating all, the available CPU and the load avg would skyrocket. Once the operators restarted jboss, the system''d be normal again (sometimes for weeks) until the next incident Since we moved the app from a v440 running Solaris 10 8/07 to a t2000 running Solaris 10 5/08 the problem started to happen more frequently (2-3 times a week). The

I have been doing some profiling using the profile provider. I have a command that runs more slowly on the T1000 than it does on prior systems and I am trying to find out why. Using the profile provider at 1000 hz, and aggregating on the ustack output, I find that the same function appears at the top of the stack on both platforms, but on each there are specific instruction locations within

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

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

I''m pleased to pass along news that the Mac OS X DTrace port has been updated in 10.5.3 to fix the issue that caused timer based probes not to fire in the presence of certain untraceable applications. http://blogs.sun.com/ahl/entry/apple_updates_dtrace A big thank you to the folks at Apple for addressing the problem. Adam -- Adam Leventhal, Fishworks