I've not tested this but can you try adding an escape char ( \ ) before the
$target as well. Shell can do bad things to it.
So something like…
dtrace -Z -n 'pid\$target::myfunc:return/arg1 == 1/ { ustack(); }' -c
/usr/bin/mycmd -a \foo bar\ -b another
-Angelo
On Sep 1, 2011, at 9:00 AM,
Hey Darren,
There is a stackdepth builtin variable that holds the depth of the stack. You
can use that to find how deep you are instead of using your own depth variable.
Also I'm not sure your script does what you think it does. You need predicates
that use the self-trace variable. Here is my
Second try. My last email bounced.
Hey Vasanth:
You can try
syscall::open:entry
/strstr(copyinstr(arg0),myapp)!=0/
{
printf(File %s, opened by process %s[%d]\n,copyinstr(arg0), execname, pid);
}
-Angelo
On Feb 16, 2011, at 9:17 AM, Vasanth Bhat wrote:
Hi,
Is there way to regex
May be if you provide the error message, we may be able to give you some help.
-Angelo
On Feb 2, 2011, at 8:28 PM, Воропаев Павел wrote:
Maybe someone can share that script with me?
Full problem i'm trying to investigate - my S10u7 get I\O error when
accessing LUN on EMC cx480, but only
This might be nit picking but a small correction in Michael's solution. Because
pid$1:libswduar::entry will match with all the functions in the libswduar
library you may want to keep the thread local timestamp for each function. So
something like
pid$1:libswduar::entry
{
Hey Mike:
Are you on trying this on a ZFS file system? See discussion here for a possible
solution.
http://www.opensolaris.org/jive/thread.jspa?messageID=497295
-Angelo
On Nov 19, 2010, at 9:07 AM, Mike DeMarco wrote:
I can not get any information out of the fileinfo structure. A simple
Hi Mike:
James is right, this is private interface. You are on your own as far as
stability is concerned.
But if you are still interested I have provided some step by step example of
using the C API in
my dtrace hands on lab. See http://dtracehol.com/#Exercise_15
-Angelo
On Nov 18, 2010, at
Slides from Jeff Savit and my session are here...
DTrace talk at Oracle Open World
-Angelo
On Oct 11, 2010, at 6:25 AM, Ewald Ertl wrote:
Hi,
On Mon, Oct 11, 2010 at 11:17 AM, Abdel Bidar abdel.bi...@sns.bskyb.com
wrote:
Hi,
Will the presentation be accessible online for
Jeff Savit I have a DTrace talk as well. This is based on some of the work
I've been doing on combining DTrace and BTrace to reduce the overhead of
observing Java applications.We show some concrete example of looking into J2EE
applications.
Wednesday, September 22, 1:00PM | Moscone South, Rm
10d\n", walltimestamp, execname, "D", uid, pid);}But when I create and remove a directory I only get a read/write event.Thank youMarkus ___dtrace-discuss mailing listdtrace-discuss@opensolaris.org
Angelo Rajadurai,Principal Software EngineerOracleDe
The error message is a little misleading. The limitation is not scratch space
but the size of the strings(strsize) in DTrace. This is 256 bytes by default.
If your strjoin is bigger than 256 bytes then you would get this error. See
Hi All:
Need some advice on the dtrace_dof_maxsize parameter.
I have a script that is hitting the DOF size limits. Changing the
dtrace_dof_maxsize from 256K to 512K in /etc/system fixes my immediate
problem. We are planing to extensively use my D-script. So just want to make
sure that it is
I guess today is my day to spam the dtrace_discuss alias!
Is there any plans for a USDT Provider wide is_enabled() check? Basically I
need to do some setup that will be used by all my probes. Would be nice if I
can put this code in a block guarded by a provider wide is_enabled().
Any idea how
Hi Srihari:
May be you can try something like
pid:::entry
/probemod!=libc.so.1/
{
}
-Angelo
On Apr 23, 2010, at 5:16 PM, Srihari Venkatesan wrote:
Hello..
In the probe entry/return statements the - provider:module:function - is
used..
Say the module is libc, then.
Hi Sabba:
You can use the ustackdepth variable. This has the stack depth in the user
land. So use that as the array index.
-Angelo
On Dec 16, 2009, at 1:52 PM, Hillel (Sabba) Markowitz wrote:
When tracing user functions, how are recursive functions handled. For
example, the following code
wrote:
On Tue, Dec 8, 2009 at 3:25 PM, Angelo Rajadurai
angelo.rajadu...@sun.com wrote:
Hi Hillel:
The second tuple in the pid probe definition is for the name of the library
and not the threadId.
You can do what want by using a predicate.
pid$target:Base::entry
/tid=3
Hi Hillel:
The second tuple in the pid probe definition is for the name of the library
and not the threadId.
You can do what want by using a predicate.
pid$target:a.out::entry
/tid=3/
{
put code here
}
HTHs
Angelo
On Dec 8, 2009, at 3:20 PM, Hillel (Sabba) Markowitz wrote:
I have
Hey Pete:
If you need to look at processes that are in the process tree of a given
process. (ie) child of a child process etc, then you can use the progenyof()
action.
You would replace the predicate /ppid == $target/ by /progenyof($target)/
HTHs
Angelo
On Nov 19, 2009, at 3:15 PM, Peter
Hey Max:
There is a built in variable ustackdepth that should provide you stack
depth in user land. See if this helps
-Angelo
On Nov 2, 2009, at 7:46 AM, Max wrote:
Hi Folks,
I'm trying to use DTrace to understand some complex code using the
user process probe.
Things are basically
. Do you know of any
workaround for that?
Cheers,
Max
On 2 Nov 2009, at 12:54, Angelo Rajadurai wrote:
Hey Max:
There is a built in variable ustackdepth that should provide you
stack depth in user land. See if this helps
-Angelo
On Nov 2, 2009, at 7:46 AM, Max wrote:
Hi Folks,
I'm
Hey Ravi:
You are trying to create a probe for every function in the oracle
binary. Is this what you want to do? By default you can have up to
25 probes in the system. Looks like you are running out of probes.
You can increase the probes by changing the fasttrap-max-probes
variable
Hi Roman:
It should be
-Angelo
#!/usr/sbin/dtrace -s
/*
* iscsiio.d - Report iSCSI I/O. Solaris Nevada, DTrace.
*
* This traces requested iSCSI data I/O events when run on an iSCSI
server.
* The output reports iSCSI read and write I/O while this script was
running.
*
* USAGE: iscsiio.d
Add a tick-10s probe to the end and do an exit. Just note that
tick-10s will fire in about 10 sec and this is not exactly at 10s.
Here is what you need to add.
tick-10s
{
exit(0);
}
-Angelo
On Oct 19, 2009, at 12:39 PM, Roman Naumenko wrote:
Hello,
I'm building some simple
Javascript is executed typically within the browser. So you would use
DTrace on the machine that is running the browser to observe the
execution. You can run dtrace as non-root user. You just need the
extra previledges (at least on Solaris its simple to get the required
previledges) See
Hi FrenKy,
You are on the right track. You can look at the write syscall. Here
are a couple of one liners that may help
If you are looking for all the processes that are writing to any
nohup,out anywhere in the system, then use
# dtrace -n syscall::write:entry'/strstr(fds
You may want to look at speculative tracing. This designed just for
this purpose
http://wikis.sun.com/display/DTrace/Speculative+Tracing
-Angelo
On Oct 2, 2009, at 9:29 AM, Joel Reymont wrote:
I have a point in my program where a timer is set up to fire as soon
as possible and another
-spec = 0;
}
On Oct 2, 2009, at 9:52 AM, Joel Reymont wrote:
On Oct 2, 2009, at 2:36 PM, Angelo Rajadurai wrote:
You may want to look at speculative tracing. This designed just for
this purpose
I'm a bit stumped, though. Consider this script below. I would like
to print statistics when
You may also find my JavaONE hands on lab useful.
http://developers.sun.com/learning/javaoneonline/j1lab.jsp?lab=LAB-9400yr=2008track=1
It talks about using DTrace for Java 1.4.2, 1.5, 6.0 and 7. You can
also see how to use it for other scripting languages, mysql and C
applications. Its
For string arguments use $$1
-Angelo
On Sep 12, 2009, at 3:07 PM, Stathis Kamperis wrote:
Greetings to everyone.
I wrote a script to calculate how much time is spent on the system
calls originating from a specific executable:
#!/usr/sbin/dtrace -s
/*
* Generate table statistics on how much
Hi Cni:
You may be able to use the strstr() subroutine (or any of its
siblings) to get what you want. Something like
#!/usr/sbin/dtrace -qs
#pragma D option destructive
syscall::write:entry
/execname == syslogd (self-class = copyinstr(arg1)) != NULL
Not sure what you mean by FD as a string. If you are trying to print
the name of the file from the FD them you can use the fds[] array.
Something like
syscall::read:entry
/pid == $1 /
{
printf(Reading (%s) \n, fds[arg0].fi_pathname);
}
-Angelo
On Aug 18, 2009, at 4:27 PM,
would
fbt::foo:entry
{
self-infoo=1;
}
fbt::foo:return
/self-infoo/
{
self-infoo=0;
}
fbt::putnext:entry
/self-infoo/
{
do what you need
}
do the trick for you?
-Angelo
On Jun 12, 2009, at 3:44 PM, rickey c weisner wrote:
In the kernel.
I am executing in function
Thanks Ryan,
This also does not explain why changing nfds_t to xx_t also has no
problem.
typedef unsigned long nfds_t; // error
typedef unsigned long xx_t; // works
-Angelo
On May 1, 2009, at 4:26 AM, Ryan Johnson wrote:
After a bit of playing around it appears that dtrace doesn't
I'm having a problem with -C flag. Any help or suggestions is very
welcome.
Here is a simple D-script.
typedef unsigned long nfds_t;
BEGIN
{
trace(success\n);
}
# dtrace -Cs test.d
dtrace: failed to compile script test.d: line 1: invalid type
declaration: signed and unsigned may
Change $1 to $target!
(ie)
./sample.d -c a.out
pid$target::somefunctionname:entry
{
printf(%s is called by %d,probefunc, tid);
}
In case you want to find the funcstions of a running process (say pid
1234)
you have two options.
./sample.d --p 1234
pid$target::somefunctionname:entry
{
By default the string size in DTrace is 256 bytes. You can change the
default by setting the strsize parameter.
**#pragma D option strsize=1024**
Hope this helps.
-Angelo
Pierre-Olivier Gaillard wrote:
Hi,
It looks like the output of copyinstr is truncated with the following
code:
Hey Thomas:
I just did a DTrace class on SunRays last week at an internal Sun Event,
We used VMWare SXE as the backend and created individual Virtual
machines for each participant. We had two pretty large servers at our
disposal so it worked ok. Please let me know if you need details but as
a
them:
http://blogs.sun.com/ahl/entry/debugging_cross_calls_on_opensolaris
Adam
On Wed, Jan 30, 2008 at 05:06:08PM -0500, Angelo Rajadurai wrote:
Hi:
I'm running Indiana (OpenSolaris developer preview) under parallels
in OS X 10.5.1. I can consistently get Solaris to hang.
Doing a
dtrace
Hi:
I'm running Indiana (OpenSolaris developer preview) under parallels
in OS X 10.5.1. I can consistently get Solaris to hang.
Doing a
dtrace -n pid\$target::malloc:entry'[EMAIL PROTECTED]()}' -c ls
will consistently hang Solaris.
Basically doing anything with PID provider with the
-c option
Hi Dan:
I typically do
dtrace -l -n *pid:::
The USDT probes are pre-initialized(may not be the right technical term)
unlike the pid probes.
Note: I also see plockstat and libCrun probes showing up in the listing.
And I assume if you have used the pid provider on the process the pid
probes will
On Jan 29, 2008, at 9:31 PM, Dan Mick wrote:
Angelo Rajadurai wrote:
Hi Dan:
I typically do
dtrace -l -n *pid:::
The USDT probes are pre-initialized(may not be the right technical
term)
unlike the pid probes.
So, it's a system-wide query?
Note: I also see plockstat and libCrun
On Jan 29, 2008, at 10:21 PM, Adam Leventhal wrote:
I typically do
dtrace -l -n *pid:::
That's interesting to know because a change we're planning is going
to make
it so that that invocation will no longer do what you want. The change
that's being made is so that a probe description
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[]=LAngelo Rajadurai;
Yikes!
Me think that this is no way to debug a problem. Why collect data that
you will never use! Just collect what you are interested in. DTrace
aggregates are excellent for this type of debugging. So you don't
spend the rest of your life going through 15 GB of text data.
Also you may want to
On Nov 7, 2007, at 1:06 PM, Angelo Rajadurai wrote:
Hi Pierre-Olivier:
You can increase the max number of probes by modifying the /kernel/
drv/fasttrap.conf
Set the fasttrap-ma-probes to a higher number. After editing you can
either reboot
or call update_drv fasttrap
Sorry typo
45 matches
Mail list logo
