similar to: Why is plockstat provider only present for 1 process

Hi - I''m trying to use plockstat to help identify any mutex contention issues we may have in our c++ app. >From the docs it would appear to be a very useful tool - unfortunately in practice this doesn''t bear out purely because the stack traces produced are limited to being 39/40 characters wide. In general this means that I''m not seeing ~75% of each stack symbol and

Hello, I need help here about plockstat on X86 platform (Sun X4600 AMD) # plockstat -A -p 20034 plockstat: processing aborted: Abort due to systemic unresponsiveness # plockstat -e 5 -s 10 -A -x bufsize=100k -x aggsize=20m -p 20034 plockstat: processing aborted: Abort due to systemic unresponsiveness # ps -ef | grep 20034 algodev 20034 1 2 07:00:54 ? 86:17

when check java process lock statistics, plockstat failed, please see below: # prstat -mLp 21162 PID USERNAME USR SYS TRP TFL DFL LCK SLP LAT VCX ICX SCL SIG PROCESS/LWPID 21162 7677 0.9 0.1 0.0 0.0 0.0 99 0.0 0.3 83 89 215 0 java/81 21162 7677 0.3 0.1 0.0 0.0 0.0 0.0 99 0.2 106 33 305 0 java/35 21162 7677 0.1 0.0 0.0 0.0 0.0 100 0.0 0.1 79 6 85 0 java/59

Hi: on a niagara platform, right after invokation of the plockstat(1M) for monitoring all events to a specific user-land process. It locks all monitored user-land processes pointer is very appreciated Thanks This message posted from opensolaris.org

Hey, Im able to reproduce a crash from plockstat everytime Im tracing a JVM pid. I do recall a problem related with this one, but not clear if this has been fixed in U3 or is it planned for U4 ? Any BugID opened for this stack trace: > ::stack libc.so.1`strlen+0x50(100003faa, ffffffff7ffff5c8, ffffffff7eca1114, ffffffff7fffec79, 0, 100003fa9) libc.so.1`snprintf+0x88(ffffffff7ffff8f0, 0,

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

I have found that pid provider can not create memcpy:return probe for 64bit process on snv_110. For example, the pid is 10603, I will have following output for dtrace command: #dtrace -n pid10603:libc.so.1:memcpy:return dtrace: invalid probe specifier pid10603:libc.so.1:memcpy:return: probe description pid10603:libc.so.1:memcpy:return does not match any probes This just

Hi, I have used dtrace in the past for diagnosing IO/filesystem related issues. So I am a bit familiar with dtrace scripts Now I want to diagnose performance problems in the java area. May be memory leak etc. The hotspot provider is not present. How can I get them? Does someone have any further advice? regards Hans -- This message posted from opensolaris.org

Hello, I am trying to get documentation how how this lazyloading happens when you are dealing with dtrace probes being added to user applications. In particular if it somehow avoids the overhead of registering dtrace probes when they aren''t needed, how does it know if they are needed, etc... thanks, Robert

Tracers, Good news! The Solaris Dynamic Tracing Guide has entered the participation age at last and has been converted into wiki format. The new and shiny guide can be found at: http://wikis.sun.com/display/DTrace/Documentation The guide has fallen behind with developments in DTrace since it was first released and needs some revising and some bug fixing as well. However, now that it''s

Tracing Fans, I know it''s been a long time in coming but the CPU Performance Counter (CPC) provider is almost here! The code is currently in for review and a proposed architecture document is attached here for review. Any and all feedback/questions on the proposed implementation is welcome. Thanks. Jon. -------------- next part -------------- An embedded and charset-unspecified text

DTraceToolkit has a dtrace script (Proc/pidpersec.d) that refers to a variable mpid as below profile:::tick-1sec { printf("%-22Y %8d %6d\n", walltimestamp, `mpid, pids); pids = 0; } Where is `mpid getting picked from (it isn''t declared anywhere else)? What does the character ` in `mpid signify? I do not see any reference to this variable in the dtrace

My leaky memory says we moved entry-point into some form of debug record in the standard libraries, circa Solaris 8/9. Before that, my group maintained text files that listed all the entry-points and their parameters for libraries like libc.so, so that we could print out parameter values in apptrace(8). There''s a (small) chance the records are complete enough that dtrace could use the

Hello all, I have been taking basic steps with DTrace and subscribed today to this list. I have written a simple DTrace script to trace all the function entry/exit from a given function: #pragma D option flowindent pid$1::*mysql_select*:entry { self -> start = vtimestamp ; } pid$1::*mysql_select*:return /self -> start/ { self -> start =0 ; } pid$1:::entry, pid$1:::return

Hi, Looking at some udp stuff on snv_57, and I noticed that mib:::udpInDatagrams no longer exists, has this been superceded by mib:::udpHCInDatagrams? From my understanding they represent the same counter, but I''m asking in case this is a bug. I noticed that there is still a reference to udpInDatagrams in the DTrace testsuite. - Fintan

Hi, Finally, the long promised CPU performance counter provider has arrived into Nevada build 109! For those that need an injection of excitement at the start of the week, you can check out some usage examples on my blog: http://blogs.sun.com/jonh/entry/finally_dtrace_meets_the_cpu Also, you can find a new section for the provider in the DTrace docs:

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 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 try to run tcptop in solaris 10 x86 with patch level 125101-04 and I get the following error /usr/include/sys/zone.h line 16: can''t find include file sys/tsol/label.h error. Is there a work around for this problem? -- This message posted from opensolaris.org

Hi all, We just got a shiny new T5440, and one of the first things I noticed (besides the insane number of hardware contexts), is that dtrace takes 30 seconds to a minute to fire up scripts with 5-6 probes, where our T5220 usually takes under a second. Shutdown is similar, though slightly faster. This is mostly annoying because it takes so long to attach that it''s hard to tell when