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
Hi Olaf,
This scripts works for me. I tried it on a Solaris 11 Express x86 machine.
You can always catch it a little early. For example when the open system call
happens.
#!/usr/sbin/dtrace -s
#pragma D option destructive
syscall::open*:entry
/copyinstr(arg0) == "./foobar.ksh" /
{
printf("o
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
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 on
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
{
@duarCount[pr
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 pro
Hi,
You can find all the built in actions in the dt_open.c source code here
http://cvs.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/lib/libdtrace/common/dt_open.c#140
Unfortunately not all of this is documented. As far as the string functions are
concerned they are identical to their C equ
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 8
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
> wrote:
> Hi,
>
>
> Will the presentation be accessible online for people who haven’t atte
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
); self->filepath = strjoin( self->filepath, stringof(args[1]) );}zfs_remove:return/ strstr(stringof(self->filepath), $1) != NULL /{ printf("%20Y%20s%8s%10d%10d\n", walltimestamp, execname, "D", uid, pid);}But when I create and remove a director
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
http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/u
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 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
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.
>
> provid
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
> 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 predicat
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 S
s off. 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
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 no
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 in
Hi Roman:
What is the error you get ? That might help pinpoint to the problem
-Angelo
On Oct 21, 2009, at 10:31 PM, Roman Naumenko wrote:
Hello,
I need some advise in sorting out the weird issue: dtrace works fine
for 3 servers, but doesn't on the 4th one.
I'm tracing iscsi initiators ac
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 monitor
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 htt
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
[arg0].fi_pathn
t;,
self->start, self->elapsed / 100, self->elapsed % 100);
}
mozilla$target:::reflow-timer-fire
/self->spec/
{
commit(self->spec);
self->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
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 wher
You may also find my JavaONE hands on lab useful.
http://developers.sun.com/learning/javaoneonline/j1lab.jsp?lab=LAB-9400&yr=2008&track=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 mea
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
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,
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 &&
strstr(self->class,"nxge_ipp_
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 functio
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
impli
ay 1, 2009, at 3:52 AM, Ryan Johnson wrote:
Angelo Rajadurai wrote:
typedef unsigned long nfds_t;
# dtrace -Cs test.d
dtrace: failed to compile script test.d: line 1: invalid type
declaration: signed and unsigned may only be used with integer type
Now if I change the typedef variable to xx_
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 o
Hi
Strings in D are 256 bytes by default. You can change the default
using the strsize pragma.
#!/usr/sbin/dtrace -s
#pragma D option strsize=1024
pid113::*mysql_parse*:entry
{
printf("%s\n",copyinstr(arg1));
}
-Angelo
On Apr 15, 2009, at 10:01 PM, Qihua Wu wrote:
Hi, All,
What's th
Hi Adam:
One of my ISVs have been looking for the atomic operation for global
variables as well. While we wait for this feature, do you have any
ideas for a reasonably good work around, now?
Thanks
Angelo
On Apr 6, 2009, at 2:25 AM, Adam Leventhal wrote:
On Apr 5, 2009, at 2:47 AM, Mich
Hi Diego:
Interestingly this same issue came up on another alias today.
Amjad Khan responded with the following detailed and useful
suggestion. Hope this helps you as well.
When a zone is created in the kernel there is a default set of "safe"
privileges which are used as a mask for all proce
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
{
My understanding was that the is enabled probe is only available in the
userland for USDT probes. What Danhua wants seems to be in the kernel.
Not sure this would work.
-Angelo
Nikita Zinoviev wrote:
> I do not remember exact details, but we have such functionality in
> dtrace support for jav
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 summ
... and your test suite has a bug.
You have
>>
>> #pragma D option quiet
>>
>> BEGIN
>> {
>> brendan();
>> exit(0);
>> }
>>
Should be
#prag
> helpful in diagnosing problems and helping us solve 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
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 s
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 desc
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
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
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
#include
#include
void
prout(wchar_t *wstr)
{
}
int
main()
{
wchar_t name[]=L"Angelo Rajadurai&
Hey Paul:
You can use the fds inlined translator to get to the file name.
For example to see all the files that are being read(2) in the system
dtrace -n syscall::read:entry'{trace(fds[arg0].fi_pathname)}'
Let me know if you need more details
-Angelo
On Nov 29, 2007, at 12:32 PM, Paul van de
Looks like Leopard perl executable does have perl probes but they are
different from the once listed in
http://blogs.sun.com/alanbur/entry/dtrace_and_perl
Here is what I did.
On one terminal ran perl and on another ran
$ ps -ef | grep perl
501 4385 4373 0 0:00.01 ttys0000:00.01 per
Hey Russ:
Try this
dtrace -n syscall::write:entry'/pid==22089/[EMAIL PROTECTED](arg2)}'
Can you send the link where you found the example below
-Angelo
On Nov 26, 2007, at 10:03 PM, Russ Petruzzelli wrote:
I am newbie trying to follow the example on page 350 of the Dtrace
guide...
I can't
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 lo
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
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"
Also you do not need the * in probe description. It defaults to wild
car
The error invalid address seems to me coming when the
pid$1::oversize:entry fires. It only has one argument but
you seem to be looking for arg1 - the second argument.
Also not sure how the script runs as you would need the
-w option for enabling destructive probes to be able to
run the system("dat
Hi Ajit:
Try the -Z option.
Basically the dvm probes take a little time to initialize. The -Z
will allow you to turn on probes that are yet to be initialized.
HTHs
Angelo
Ajit Bansode wrote:
> Hi all,
> There is one command in solaris called jmplay which starts java media player.
>
> When I a
You may find the -Z option useful for this purpose. It will allow
you to enable probes that are not yet active. Remember to use the
full library name not just the alias.
HTH
Angelo
Sean Liu wrote:
> Hi there,
>
> I've been trying to figure out some PAM issue, however it's difficult to use
> dT
61 matches
Mail list logo
