On Fri, Dec 17, 2010 at 03:44:00PM -0500, Brian Utterback wrote:
I am aggregating using the stack function as the index:
@s[stack()] = count();
This works great. However, I found that in addition to how many times
each stack appears, it would also be useful to know which stacks were
On Fri, Oct 15, 2010 at 04:08:25PM -0700, Darren Reed wrote:
At present, dtrace does not support conditional execution,
so no if's and no loops.
There's the ? : operator...
With the current design, all collection of statistics is about
something that is happening. This means I can't present
On Mon, Aug 30, 2010 at 10:17:53AM -0700, Jonathan Adams wrote:
On Fri, Aug 27, 2010 at 04:44:31PM -0700, Rafael Vanoni wrote:
I was trying to aggregate on the stack trace of a CPU's current
thread from a cpu_t * and the best I could do was aggregating with
sym() on the t_startpc field of
On Mon, Aug 30, 2010 at 10:42:27AM -0700, Jonathan Adams wrote:
On Mon, Aug 30, 2010 at 12:29:18PM -0500, Nicolas Williams wrote:
Can't this be done with dtrace_xcall()?
You can't cross-call from probe context, let alone wait for one to complete.
dtrace_xcall() is used by the dtrace
On Wed, May 12, 2010 at 06:53:47PM +0200, Mark Phalan wrote:
Are the padding rules supposed to be consistent between the compiler and
dtrace on x64?
# cat /tmp/s.d
...
# cat /tmp/s.d
...
Did you mean to catn /tmp/x.c and /tmp/s.d?
$ cc -m64 /tmp/x.c -o /tmp/x
Dunno what x.c
On Tue, May 11, 2010 at 07:38:17AM +0200, Michael Schuster wrote:
On 10.05.10 21:01, William Reich wrote:
only this process fails -
./adc.d 24930
dtrace: failed to compile script ./adc.d: line 7: failed to grab
process 24930
Isn't this what happens if a process is already being traced
On Fri, May 07, 2010 at 12:38:02PM -0700, tester wrote:
Hello,
How can I access frame pointer? I am trying to get a variable value. Here is
the disassembly of the function.
function+0x208:st%l0, [%fp - 0xc]
I am trying to the value at [%fp - 0xc]
You can access the
On Fri, May 07, 2010 at 12:56:25PM -0700, tester wrote:
Do I need to add stack bias 2047to fp to get actual data?
On 64-bit SPARC, yes.
Nico
--
___
dtrace-discuss mailing list
dtrace-discuss@opensolaris.org
On Wed, May 05, 2010 at 09:11:27AM -0700, Yossi Lev wrote:
I just found a function that (sort of) does what I need: it is called
lltostr and it takes a long long integer, and returns a string that
represents it. (Unfortunately I didn't find an option to do the
translation in hexadecimal, but
On Fri, Apr 30, 2010 at 05:39:13PM +0200, Mark Phalan wrote:
http://wikis.sun.com/display/DTrace/kerberos+Provider
I've reviewed already, but I'd like to add one more thing: probes for
KDB lookup start/end, with end getting the KDB record fields, could be
very useful as well (e.g., to help with
On Wed, Apr 07, 2010 at 05:08:07PM +0200, Mark Phalan wrote:
I'm working on a set of USDT probes and need to expose fairly complex
data in a reasonable way. I'd like to build up some compound structures
but dtrace doesn't seem to like translating them :(
The PID provider and USDT do not give
On Wed, Apr 07, 2010 at 06:15:22PM +0200, Mark Phalan wrote:
But this isn't about user-land data. The structs I'm talking about
are dtrace native structs defined in the d script. In the example I
gave I wasn't even tracing a program - it was pure d. CTF data
doesn't come into it...
Duh.
On Wed, Apr 07, 2010 at 06:41:35PM +0200, Mark Phalan wrote:
I guess I wasn't too clear.. I don't have any problems writing
translators for simple structs. My problem is when the struct
contains another struct which I'd like to initialize/set in the
translator.
No, it was clear the second
On Fri, Mar 19, 2010 at 12:31:04PM +, Mark R. Bowyer wrote:
Now, first glance, I asked why they were monitoring a 64-bit application
with 32-bit code. But they do, and everywhere else they manage it.
You can't do that. What they are trying to do is observe a 32-bit
user-land application
On Tue, Mar 16, 2010 at 08:55:04AM -0700, tester wrote:
It is somewhat complex for someone like me with limited C programming
to unearth the actual data(args and result) from the door call API. I
beleive it has custom NSS headers packed along with actual data.
Tracemem for most part is not
On Mon, Mar 15, 2010 at 12:20:35PM -0700, tester wrote:
#!/usr/sbin/dtrace -qs
typedef struct door_arg {
char *data_ptr; /* Argument/result buf ptr*/
size_t data_size; /* Argument/result buf size */
door_desc_t *desc_ptr;
On Sun, Mar 14, 2010 at 07:42:08PM -0700, tester wrote:
Ouch, copyin bites again.
Remember: copyin() returns the kernel address of the buffer into which
it copied the data that you asked for. To get to the data you have to
dereference that pointer.
BTW, can you please explain the 8 byte
On Tue, Feb 16, 2010 at 02:12:35PM +0100, Mark Phalan wrote:
I'm working on adding USDT probes to a library. The library is built in
ON and hence includes CTF data. I've set up a number of translators for
the probes to use to avoid exposing the internals of the library.
Unfortunately it
On Mon, Dec 21, 2009 at 07:19:35AM -0800, tester wrote:
Yes, a T5220.
You're printing the thread ID, which is good. But, suppose thre thread
in question gets re-scheduled on a different processor (or hw thread).
DTrace has a per-CPU trace log... You can see how such re-ordering
might happen
On Thu, Dec 17, 2009 at 09:16:24AM -0800, GGallagher wrote:
On Solaris 10, running 'pstack' against our JVMs (java version
1.5.0_17) can take as long as 60 seconds to complete. During that
time apparently, the JVM is unable to do anything else. This causes
applications to crash. So they said
On Wed, Oct 28, 2009 at 06:55:28PM +, Joel Reymont wrote:
I have a script where I can freely reference struct nameidata*, struct
vnode*, etc. on Snow Leopard.
How does DTrace know about these data types? I understand things like
#pragma D depends_on library darwin.d
where darwin.d
On Sat, Oct 10, 2009 at 07:56:14AM -0700, Martin Cerveny wrote:
PS: I understand that there is the error in PCFS (I will probably find
and correct the problem), but I am very disappointed by dtracing side
effect This breaks non intrusiveness of dtrace.
All DTrace did here was have some
On Fri, Aug 28, 2009 at 05:13:41PM -0400, Chad Mynhier wrote:
On Fri, Aug 28, 2009 at 4:44 PM, Nicolas
Williamsnicolas.willi...@sun.com wrote:
Don't forget to have a system(prun $pid); action in the BEGIN probe of
the second script...
Nope, DTrace will actually take care of that for you.
On Wed, Jun 10, 2009 at 05:09:38PM -0700, Randy Fishel wrote:
Where I eventually landed, is that I need to have (or implement) a
mechanism to send dtrace information to an arbitrarily defined
streaming device. I was considering it as part of a 'power
management' provider, but it seemed
On Thu, Jun 11, 2009 at 01:15:14PM -0400, Colin Burgess wrote:
Do you mean that the raw data would be sent (rather than being placed into
buffers?) or that the dtrace util would spit out it's info to the port?
The user-land part of dtrace wouldn't be running, so I'm sure Randy
meant the former.
On Wed, Jun 10, 2009 at 04:15:30PM -0700, Randy Fishel wrote:
This morning I had the thought that maybe some or all of this
functionality could be handled by having a 'logger' provider in
dtrace. My needs are to have a lightweight non-volatile logging
mechansim that will continue to
On Thu, Jan 29, 2009 at 01:48:05PM -0800, Glenn Skinner wrote:
syscall::write:entry
/pid == $target arg0 == 1/
{
interesting = 1;
printf(writing 0x%x bytes to stdout at 0x%x\n,
arg2, fds[1].fi_offset);
}
syscall::write:return
/pid == $target interesting == 1/
On Tue, Jan 20, 2009 at 09:33:42AM -0800, Rob Clark wrote:
Summary comparing systemtap and dtrace
http://sourceware.org/systemtap/wiki/SystemtapDtraceComparison
It looks like we are ahead in a few spots also.
We being DTrace?
That comparison is wrong or misleading in a number of areas. For
On Fri, Jan 16, 2009 at 02:03:48PM -0500, Chip Bennett wrote:
and for the C API (libdtrace):
http://dev.lrem.net/tcldtrace/wiki/LibDtrace
Oh, and there's a tantalizing link to a Tcl interface, not yet
populated, and an even more tantalizing link to what a TclDTrace script
would look like!
On Wed, Dec 17, 2008 at 10:53:28PM +0800, Jason Zhao wrote:
I have a quick question, I run the following dtrace command on my Lenovo
T61 which is 64-bit kernel running.
But after that, I found the dtrace return 32-bit address, otherthan
64-bit address, why does that happen?
Does that mean
On Fri, Dec 12, 2008 at 09:45:08AM -0500, James Carlson wrote:
Chip Bennett writes:
Pfiles should be rewritten to not stop processes. I had to go look at
the code to make sure you were right on this. If lsof can gather open
file info without stopping processes, why can't pfiles do that.
On Fri, Dec 12, 2008 at 02:00:25PM -0800, Dan Mick wrote:
For the record: 'kmdb' and 'mdb -k' are different beasts. kmdb == mdb
-K == boot with -k ==
console only == stop the kernel in its tracks. mdb -k is have a
gander at the still-running kernel.
I knew I'd get in trouble over that
On Wed, Oct 01, 2008 at 12:59:15PM -0700, Adam Leventhal wrote:
On Wed, Oct 01, 2008 at 12:16:07AM -0500, Nicolas Williams wrote:
pid$1:libsomelibrary:some_function:entry
{
self-some_item = copyin_expr(arg[0]-field1-field2-field3);
...
}
and the D *compiler* looking up
On Wed, Oct 01, 2008 at 01:00:52PM -0700, Adam Leventhal wrote:
On Wed, Oct 01, 2008 at 12:02:04PM -0700, Paul Macknee wrote:
The alternative I see, is to need to know the usage about each syscall (all
hundreds of them) and write hundreds of separate probes that know how the
arguments are
On Wed, Jun 11, 2008 at 11:45:05AM -0400, James Carlson wrote:
Andrew Gallatin writes:
Just that that the second snippet seems to be rather
recursive (this-mp = this-mp-b_cont) and it seems
to work, and is a nice alternative to enumerating
all the potential chains as was suggested.
On Mon, Apr 21, 2008 at 11:00:29AM -0700, Adam Leventhal wrote:
So curlwpsinfo-pr_stype can work and later fail. Looking at the translator
for that field we see that it looks like this:
pr_stype = T-t_sobj_ops ? T-t_sobj_ops-sobj_type : 0;
This compiles to this DIF code:
[...]
On Mon, Mar 24, 2008 at 10:35:43AM -0700, Roman Shaposhnik wrote:
Any suggestions?
Either don't use DTrace if you need to iterate, or start the target via
DTrace so you can keep track of all the LWPs in your D script.
___
dtrace-discuss mailing list
What I meant by the don't use DTrace if you need to iterate option is
this: try using MDB. Given what you say you might find it a lot easier
to sample the items you need via MDB.
___
dtrace-discuss mailing list
dtrace-discuss@opensolaris.org
On Sun, Feb 03, 2008 at 01:34:02PM -0800, Adam Leventhal wrote:
I'm not sure why we don't include the evaluation in the public version, but
here it is:
---8---
Evaluation
[ahl 8.9.2007]
unlink(2) and unlinkat(2) are different system calls. unlinkat(2) is
On Mon, Feb 04, 2008 at 05:44:05PM +0100, Joerg Schilling wrote:
Nicolas Williams [EMAIL PROTECTED] wrote:
This pig isn't very attractive. Is a system call number shortage the
underlying problem? And is the fix to this ultimately about fixing the
syscall number shortage?
grouping
I see that rm(1) uses unlinkat(2), but I don't see a syscall provider
probe for unlinkat(2). That's... annoying (but there's always the fbt
provider).
Actually, I don't see any syscall provider probes for any of the
open/unlink/rename/...at[64]() system calls. Is there a CR for this?
Nico
--
On Fri, Feb 01, 2008 at 01:09:22PM -0500, James Carlson wrote:
Nicolas Williams writes:
I see that rm(1) uses unlinkat(2), but I don't see a syscall provider
probe for unlinkat(2). That's... annoying (but there's always the fbt
provider).
Actually, I don't see any syscall provider
On Thu, Jan 24, 2008 at 09:58:32AM -0800, Fletcher Cocquyt wrote:
Fellow dtracers - I am diagnosing a busy spamassassin/mailman/sendmail
system - the CPU and memory usage seems normal, but iotop shows I/O and
network are very busy (and initiating TCP connections is quite slow
sometimes (even
On Wed, Dec 05, 2007 at 12:05:04PM -0500, Brian Utterback wrote:
And just to make sure, if I want to see the values in
the struct when ntp_adjtime returns, I need to do the
copyin again, right?
Or use fbt.
___
dtrace-discuss mailing list
On Wed, Nov 21, 2007 at 09:58:49AM -0800, Bryan Cantrill wrote:
We wanted to develop a dtrace script that would capture the raw data
that would be used to modify the internal database just before it was
actually used to update the database. I have written this script, and
it does dump
On Thu, Nov 15, 2007 at 06:43:07PM -0600, Spencer Shepler wrote:
On Nov 15, 2007, at 4:27 PM, Adam Leventhal wrote:
Does 4.1 differ so much from 4 that the provider name itself must
differ?
That's funny. Yes.
How funny is it? Will we want to support both the nfsv4 and nfsv41
On Fri, Nov 16, 2007 at 01:53:05PM -0800, Adam Leventhal wrote:
On Fri, Nov 16, 2007 at 03:20:02PM -0600, Spencer Shepler wrote:
On Fri, Nov 16, 2007 at 12:58:19PM -0600, Nicolas Williams wrote:
(I.e., drop the op- in the client-server compound direction.)
We chose to include 'op
On Wed, Aug 29, 2007 at 11:31:13AM -0700, Martin Englund wrote:
Thanks for the suggestion. This is how the probes fire:
fbt:c2audit:audit_start:entry
fbt:c2audit:audit_start:return
syscall:::entry
syscall:::return
fbt:c2audit:audit_finish:entry
fbt:c2audit:audit_finish:return
I guess I
48 matches
Mail list logo
