similar to: query re memory profiling

Hi all, I am trying to write a D script which would print ustack() for every program in the system receiving SIGSEGV. All the stacks printed in trap()/sigtoproc() context do not have meaningful symbols. The following solves the problem to some degree but I''d much rather have a self-contained D script. dtrace -w -n ''fbt:genunix:sigtoproc:entry/arg2 == 11/ {

Hi i''m trying to write my first dtrace script apparently i bit off a bit more than i can chew, i want to track io over sockets, i found your socketsize.d that gave me how to track writes, but i''m at a loss how to track reads, frankly i don''t see how your write tracker works because it uses a probe in a function that only takes two arguments but you grab size of write

I''m using a fbt probe where I get a system call id as an argument, how do I look up the name of it? At the moment I''m post-processing the output using /etc/name/to_sysnum but that doesn''t feel right :) cheers, /Martin -- This message posted from opensolaris.org

I''ve been trying to get access to a userland string that''s behind a second level pointer using DTrace, but I can''t seem to get it to work. I started with the example on the Team DTrace Tips and Tricks slides: trace(copyinstr(*(uintptr_t *)copyin(arg0, curpsinfo->pr_dmodel == PR_MODEL_ILP32 ? 4 : 8))); And when I couldn''t get it to work, I started

Hiya, I''m trying to track down some throughput latency that our customer seems to be attributing to our product, I can''t see what he''s talking about, but I want to try and get some deeper granularity than I might get with something like smokeping, and maybe even see if its down to something tunable on our end. I''ve been looking for some examples on how

Hi all, OK, so this at first looked like a clear cut "Don''t do it, or at worst handle the results" issue my customer has come to me with, but the more we discuss it, the more it looks like we should have better ways of dealing with this issue. > We have user defined dtrace probe points in the application which use > as parameter 64 bit values: > > provider adv {

Hi. System is snv_56 sun4u sparc SUNW,Sun-Fire-V440, zil_disable=1 We see many operation on nfs clients to that server really slow (like 90 seconds for unlink()). It''s not a problem with network, there''s also plenty oc CPU available. Storage isn''t saturated either. First strange thing - normally on that server nfsd has about 1500-2500 number of threads. I did

Hello ZFS, System was rebooted and after reboot server again System is snv_39, SPARC, T2000 bash-3.00# ptree 7 /lib/svc/bin/svc.startd -s 163 /sbin/sh /lib/svc/method/fs-local 254 /usr/sbin/zfs mount -a [...] bash-3.00# zfs list|wc -l 46 Using df I can see most file systems are already mounted. > ::ps!grep zfs R 254 163 7 7 0 0x4a004000

Hi, Following "anonymous tracing" chapter, I wanna trace kmem_init(), but after reboot, I can''t get anything, why? Here is my short script kmem_init.d: #!/usr/sbin/dtrace -s fbt::kmem_init:entry { stack(); } then I just use: #dtrace -AFs kmem_init.d #reboot #dtrace -ae < got nothing here> Thanks, -Alex This message posted from opensolaris.org

I would like to know how to get access to errno when using pid provider to probe calls to libc functions like fopen(). The built-in errno appears to be only for system calls. What I''d like to be able to do is investigate where in an application I''m encountering EMFILE and what the stack looks like at the time. This message posted from opensolaris.org

OK, I''ve been fritzing around with something I noticed last night, thinking that I understood what was going on, but now it''s getting confusing again. A system that has been running for a couple of months had a hole in the probe ID list near the end in the middle of the fbt probes. And then a couple of syscall probes were stuck in the hole. It looked like this: ... 40311

If I use a simple dtrace script such as this: fbt::somefunc:entry{self->trace=1;} fbt::somefunc:return{self->trace=0;} fbt:::entry{} fbt:::return{printf("%lx", arg1);} then it will descend to whatever depth is necessary If I want to limit it to say 3 functions deep, how can I do that? The quick answer I want to use is to do "self->depth++" on each entry and then

Hi all, I have questions about something I observed just now: 1) on AMD64, S10u1: # dtrace -n ''fbt::copystr:entry{printf ("%p\n", args[0]);}'' -c /bin/pwd dtrace: invalid probe specifier fbt::copystr:entry{printf ("%p\n", args[0]);}: in action list: index 0 is out of range for fbt::copystr:entry args[ ] but # dtrace -n ''fbt::copystr:entry{printf

what is differenct between syscall::write:entry fbt::write:entry are the two probe fires at the same place. -- This message posted from opensolaris.org

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

Tried to start up tcptop_snv on snv87 x86 and got <i>dtrace: failed to compile script /dev/fd/11: line 168: conn_tcp is not a member of struct conn_s</i> Line 288 has this line: <i>this->tcpp = (tcp_t *)this->connp->conn_tcp;</i> which, after looking at line 168 of <a

Hi. I would like to print out a field of a vnode, but the argument to the function is of type vnode_t **. If I set "this->vpp" to arg2 in an entry function to zfs_lookup(), I''d like to retrieve the value of one of the fields of *(this->vpp) in the return function. Something like the below (but the syntax below is not right): printf("zfs_lookup:

I''m curious to know what files are being used from a NFS server perspective. I''m unable to trace the client because it is in the boot phase. Looking at the io provider, I believe it does not allow you to look at what files are being requested. That would lead me to the fbt provider. Does anyone know what fbt provides the file handle for NFS client request on the NFS

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

Referring to the DTrace manual: "Module If this probe corresponds to a specific program location, the name of the module in which the probe is located. This name is either the name of a kernel module or the name of a user library. Function If this probe corresponds to a specific program location, the name of the program function in which the probe is located." and then ...