similar to: dtrace-discuss Digest, Vol 69, Issue 2

Hi, I am kind of new to DTrace , I have written a script to time function calls in our application library , Wanted to know how to interpret the output from quantize of the elapsed time in each function call , here is a sample Here is the entry and return function for the library that is being traced pid$1:libswduar::entry { duarEntry[probefunc] = timestamp;

Hi, This is regarding Dtrace usability for memory leak detection. We have real-time application written C++ which runs on Solaris 10 having a problem that''s the my application grows in size from 130 Mb to 450Mb in around 15 days. So there is two possibilities with the application growth of memory due to Size growth of Dictionary Objects (Like Maps) and Memory Leak.

i am doing reads and writes to /dev/rdsk/c0t2d0s4 using dtrace to see how much time it took for ssdread and ssdwrite. It shows very small number 4 or 5. #pragma D option flowindent syscall::pread:entry { self->trace = 1; self->size = arg2; } syscall::pwrite:entry { self->trace = 1; self->size = arg2; } fbt:ssd:ssdread:entry /self->trace/ { self->start = timestamp;

We are using following dtrace script to analyze an application. However we see different number of lwp_yield and yield calls reported depending on whether we trace mutex_lock or mutex_unlock or not. The number reported when we are not tracing mutex_lock or mutex_unlock is higher. What could be going on here and which one is the correct number. This is on S10 U2. Thanks, Rao.

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

[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

Hello, I''m using the below dtrace script to capture the flow and times of kernel functions, from an ioctl() call. After an entry into restorectx(), the trace of startimestamp - vtimestamp makes a dramatic jump downwards. Here''s the snippet showing the jump... 6 -> di_checkmem 8 220176600 6 <- di_checkmem

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);}

I''m wondering if I should file a bug against this or is this just a case of a user doing something stupid :) I ran the following script on my desktop: #!/usr/sbin/dtrace -s pid9276:::entry { @counting[probefunc] = count(); } And my Xsession immediately crashed and through me back to the login screen. My OS is 5.11 snv_50 i86pc i386 i86pc with a dual core amd chip and 2G or

[1] Predicates in one-liners I would like to list the probe modules in my executable and then dynamically create a dscript to trace execution of those modules alone (by excluding the 3rd party and system libraries). I tried the below script without success. The conditional given in the predicate is not taking effect. Why is this so ? $ dtrace -ln ''pid$target:::

Just showing someone how great DTrace is and then we spot something I do not understand. Of course it can be a major misunderstanding of myself. Would appreciate another (expert) look upon this. The goal we try to achieve is trying to get insight if there is a bursty nature in the time slot when system calls are done. Following DTrace snippet is tried: dtrace -q -p 3173 -n

everyone Here: How do you do! dtrace is interesting. I am studing how to write dtrace script and analyze situation. I read dtrace_example.pdf and 819-6959.pdf document more than five times with careful. because I am newbie to studing dtrace.so I still don''t know how to begin. for question: 1. What consumes time? 2. Which system call(s) consume(s) time?

Hello all, I saw this question about a year back in the archive[1], but with no final answer. I would like to trace shmget calls and also get the id of the shared memory segment. That script looked like[2], but we dont get the id since arg1 is the errno value. How do i access the shm id, i would need this to debug a customer problem but i don''t have time to learn it the hard

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

A user has asked us to find out who is changing one of their files and how it is being changed. I came up with the script below: #!/usr/sbin/dtrace -s #pragma D option quiet BEGIN { printf("\n Timestamp gid uid pid ppid execname function current directory file name\n\n"); } syscall::open:entry,

I have a probe: pid111::myfunc:entry { self->arg = arg0; } pid111::myfunc:return /self->arg/ { @[self->arg] = quantize(); } works great, but i''d like arg0 to be printed in hex. I''ve tried numerous approaches to do this but i''ve hit a wall every time. I''ve tried: 1) self->arg = sprintf(arg0); no, cuz dtrace has no sprintf 2) self->arg

Recently I found that the mac_srs_rx_poll_ring thread may never stop in kernel, please see the following mpstat, cpu 2 is in 100% kernel usage, but no syscalls and no interrupts. CPU minf mjf xcal intr ithr csw icsw migr smtx srw syscl usr sys wt idl 0 0 0 0 300 100 0 0 1 0 0 0 0 0 0 100 1 14 0 0 134 68 134 1

(PS: another idea that comes along the same lines as a dumper function and IMO would be helpful is an ''introspect'' function. Given an argument: introspect(probefunc) it returns back the expected arguments for the probe func, their datastructures, as well as the syntax on how to dereference them. If an intelligent copyinstr comes out, this would be easy to write, and would

Hopefully this is a straight forward issue and I''m missing something obvious. I''m trying to print a wchar_t [] argument from a simple example program like #include <stdio.h> #include <wchar.h> #include <unistd.h> void prout(wchar_t *wstr) { } int main() { wchar_t name[]=L"Angelo Rajadurai"; int i; for(i=0; i<1000 ; i++) { prout(name);

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?