similar to: Project proposal for enhanced ustack/jstack

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

Howdy, I was playing around with the malloc/free D script provided by Philip Beevers: http://www.opensolaris.org/jive/thread.jspa?threadID=4224&tstart=15 And decided to change the free:entry probe from: pid24169::free:entry / sz[arg0] / { printf("Freeing %p (size %d)\n", arg0, sz[arg0]); sz[arg0] = 0; } to: pid24169::free:entry / ! sz[arg0] / { printf("[ *

Hi Ryan, > Does anyone happen to know why the ustack() doesn''t show lex, > yak, main > and _start? A quick look with the source browser seems to indicate that _rt_boot is code executed very early in the lifetime of your process by ld.so.1. What seems to be happening is that ld.so.1 has allocated some memory before DTrace got control of your process - long before main() was

Hi all i want to view the stack trace of the real time java application using DTrace probes. i am using jrts provider for finding the information of real time threads. In this i have used the ustack(), jstack() and this gives the following type of information libjvm.so`__1cJJavaCallsMcall_virtual6FpnJJavaValue_nGHandle_nLKlassHandle_nMsymbolHandle_5pnGThread__v_+0x5e

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

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

Author: bmc Repository: /hg/zfs-crypto/gate Revision: 213bfe03af413cdf71c523fb076aaa65a6306a7e Log message: 6256581 System got a hang or a panic with dtrace+kmdb 6264573 unanchored dtrace_getpcstack is rather imprecise toward function end 6289517 dtrace doesn''t like fd_intr anymore 6291378 dtrace helpers can interfere with the use of kmdb 6295554 dtrace doesn''t report

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 fairly new to DTrace, and wanted to ask something regarding synchronization objects. I have a multithreaded C++ program in which I use semaphores (POSIX version) for synchronization. I was interested in using DTrace to figure out the total time for which each thread in my application sleeps, blocked on a semaphore, i.e., as a result of sem_wait() call. In order to measure this, I

Opening folders containing 10K files totaling 20GB is slow (takes 1.5 - 2.0 minutes) in FreeBSD 9.2 with Samba 4.1.11 on a system with 32GB RAM and a newer Xeon processor. Server is a standalone server that I'm using for testing. I am using nfsv4 acls. I used the procsystime dtrace script from here: http://www.brendangregg.com/DTrace/procsystime with the following syntax: procsystime -n smbd

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

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

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

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

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

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

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

Francois Dion wrote: > Le lundi 16 avril 2007 ? 13:28 -0600, Ali Bahrami a ??crit : >>> Subject: >>> Re: [dtrace-discuss] Getting the function names? >>> From: >>> Bart Smaalders <bart.smaalders at Sun.COM> >>> Date: >>> Fri, 13 Apr 2007 09:48:29 -0700 >>> To: >>> fdion at atriumwindows.com >>> >>>

Hi, Yufei: Thanks for your kind action. Let me centralize all the harm-hearted guys and involved alias in one email. Below is the answer of your question (Can you reply with more details on what failed? Does websphere use an IBM or Sun developed SDK? ) 1. Seems IBM bundled JDK can not detect agent options, like below: If use Sun JDK 1.5, no problem: /usr/jdk/jdk1.5.0_06/bin/java