Once I''ve found the specific process I am interested in tracing (using progenyof and execname) how do I arrange to use pid$xx::: on it? The pid number used in the provider name for the pid provider has to be known at dtrace compile-time right? (That''s the way it seems to work). I want to trace the process when it enters a certain user function. Is there any way for me to do that with a dynamically chosen pid? Is the pid provider the only one that can trace user functions? --chris
Chris,
I don''t think you can instrument probes in "D" after the D
program
starts executing, unless there is a new feature to do that. (I wonder
if there is some reason this is not practical.)
However, assuming you are only looking for the first hit, you could do
something like:
pidtrace.d `pidlist.d -c command`
where pidlist.d is a DTrace program that only prints out the PID when it
finds it, and pidtrace.d is a DTrace program which passes the PID as the
$1 macro to be used with a pid-provider probe specification (i.e.
pid$1::userfunc:entry)
If pidlist.d is going to produce more than one PID, you might pipe
standard out to a shell script that spawns pidtrace.d, in background,
for each PID, but the standard out from each occurrence will probably be
commingled, unless you route each one to a unique file.
FYI: I''d be willing to bet you can''t guarantee that you will
trace the
first calls to "userfunc" in "prog", since "prog"
could have called
"userfunc" many times before "pidtrace.d" even gets set up.
Hope this helps,
Chip Bennett
Laurus Technologies, Inc
Chris Quenelle wrote:
>
> Once I''ve found the specific process I am interested in tracing
> (using progenyof and execname) how do I arrange to use
> pid$xx::: on it?
>
> The pid number used in the provider name for the pid provider has
> to be known at dtrace compile-time right? (That''s the way it
> seems to work). I want to trace the process when it enters a
> certain user function. Is there any way for me to do that
> with a dynamically chosen pid?
>
> Is the pid provider the only one that can trace user functions?
>
> --chris
>
> _______________________________________________
> dtrace-discuss mailing list
> dtrace-discuss at opensolaris.org
Chip (and Rod Evans in private email) both suggested that I use two different scripts for this. That approach seems promising. I actually want to: 1. find a specific process in a tree (the first matching one, for now) 2. step this process forward until a certain point, then stop() it So my next avenue of attack will be to do step 1 in one dtrace script, and stop the process usig stop(). Then use another dtrace script to attach to the process and continue it until the interesting point. (At this point the process will be ready to attach to with a debugger). Is there a corresponding cont() command to undo a stop() command? I would want to use that from the BEGIN clause in my dtrace script. I can''t use /bin/prun because the process would run away, and I would miss the dtrace event I''m looking for. --chris
Chris, Quoting the DTrace guide: "The stop() action forces the process that fires the enabled probe to stop when it next leaves the kernel, as if stopped by a proc(4) action. The prun(1) utility may be used to resume a process that has been stopped by the stop() action. The stop() action can be used to stop a process at any DTrace probe point. This action can be used to capture a program in a particular state that would be difficult to achieve with a simple breakpoint, and then attach a traditional debugger like mdb(1) to the process. You can also use the gcore(1) utility to save the state of a stopped process in a core file for later analysis." As far as I can tell there is no "cont()" function in DTrace. But this way of getting mdb attached to the process bothers me. Here''s why: your DTrace program is a consumer on a 4M buffer. The DTrace probes are producing data into the same buffer. Because of the buffer, your application could be way ahead of what your DTrace program sees. You wouldn''t want it any other way, as it would severely impact the performance of the system. Assuming I have this right, how could you know the application process state at the point where your DTrace program issues the "stop" action. By the time the DTrace program sees the buffer data that indicates there was an "exec" of a new executable, that executable could have already stepped through a million instructions. If hate to disagree with the DTrace guide, but I don''t see how this can work. So, OK, what am I not seeing? :-) Chip Bennett Laurus Technologies, Inc. Chris Quenelle wrote:> > Chip (and Rod Evans in private email) both suggested that I > use two different scripts for this. That approach seems > promising. > > I actually want to: > 1. find a specific process in a tree (the first matching one, for now) > 2. step this process forward until a certain point, then stop() it > > So my next avenue of attack will be to do step 1 in one dtrace > script, and stop the process usig stop(). Then use another dtrace script > to attach to the process and continue it until the interesting point. > > (At this point the process will be ready to attach to with a debugger). > > Is there a corresponding cont() command to undo a stop() command? > I would want to use that from the BEGIN clause in my dtrace script. > I can''t use /bin/prun because the process would run away, and I would > miss the dtrace event I''m looking for. > > --chris >
On Thu, Jun 01, 2006 at 05:14:28PM -0500, Chip Bennett wrote:> Assuming I have this right, how could you know the application process > state at the point where your DTrace program issues the "stop" action.stop() is synchronous, IIRC, in probe context.
Hi Chip,
A couple of points that need some clarification:
The stop() action is synchronous (at least with respect to application
activity); the system() action, however, is processed along with traced data.
There''s no cont() action (obviously since a stopped process
can''t hit any
probes where we could use such an action), but you can use
''system("prun %d",
pid)'' to effect something similar.
Notice that if you do something like this:
syscall::open:return
/pid == $target/
{
stop();
system("prun %d", pid);
}
you can be certain that while the application may, as you say, be ahead of
the information that''s been processed by the DTrace consumer, the
processing
of the system action will take place after that information has been consumed.
Adam
On Thu, Jun 01, 2006 at 05:14:28PM -0500, Chip Bennett
wrote:> Chris,
>
> Quoting the DTrace guide:
>
> "The stop() action forces the process that fires the enabled probe to
> stop when it next
> leaves the kernel, as if stopped by a proc(4) action. The prun(1)
> utility may be used
> to resume a process that has been stopped by the stop() action. The
> stop() action
> can be used to stop a process at any DTrace probe point. This action can
> be used to
> capture a program in a particular state that would be difficult to
> achieve with a simple
> breakpoint, and then attach a traditional debugger like mdb(1) to the
> process. You can
> also use the gcore(1) utility to save the state of a stopped process in
> a core file for
> later analysis."
>
> As far as I can tell there is no "cont()" function in DTrace.
But this
> way of getting mdb attached to the process bothers me. Here''s
why:
> your DTrace program is a consumer on a 4M buffer. The DTrace probes are
> producing data into the same buffer. Because of the buffer, your
> application could be way ahead of what your DTrace program sees. You
> wouldn''t want it any other way, as it would severely impact the
> performance of the system.
>
> Assuming I have this right, how could you know the application process
> state at the point where your DTrace program issues the "stop"
action.
> By the time the DTrace program sees the buffer data that indicates there
> was an "exec" of a new executable, that executable could have
already
> stepped through a million instructions.
>
> If hate to disagree with the DTrace guide, but I don''t see how
this can
> work. So, OK, what am I not seeing? :-)
>
> Chip Bennett
> Laurus Technologies, Inc.
>
> Chris Quenelle wrote:
>
> >
> >Chip (and Rod Evans in private email) both suggested that I
> >use two different scripts for this. That approach seems
> >promising.
> >
> >I actually want to:
> > 1. find a specific process in a tree (the first matching one, for
now)
> > 2. step this process forward until a certain point, then stop() it
> >
> >So my next avenue of attack will be to do step 1 in one dtrace
> >script, and stop the process usig stop(). Then use another dtrace
script
> >to attach to the process and continue it until the interesting point.
> >
> >(At this point the process will be ready to attach to with a debugger).
> >
> >Is there a corresponding cont() command to undo a stop() command?
> >I would want to use that from the BEGIN clause in my dtrace script.
> >I can''t use /bin/prun because the process would run away, and
I would
> >miss the dtrace event I''m looking for.
> >
> >--chris
> >
>
> _______________________________________________
> dtrace-discuss mailing list
> dtrace-discuss at opensolaris.org
--
Adam Leventhal, Solaris Kernel Development http://blogs.sun.com/ahl
> Is there a corresponding cont() command to undo a stop() command? > I would want to use that from the BEGIN clause in my dtrace script. > I can''t use /bin/prun because the process would run away, and I would > miss the dtrace event I''m looking for.Thanks Adam for joggin my noggin. Obviously, if you run the prun command from inside dtrace, you''ll get the chance to trap any and all events that happen immediately after the program starts running again. If there WAS a cont() command, the only useful place to use it would be in a BEGIN clause. But there''s no need, since system("prun") does the same thing (albeit a little slower). --chris
Hi Adam/Nicolas/Chris, Oops. I dropped a brain cell. Why was I thinking actions were passed through the buffer and processed by the consumer? I knew better. I should have re-read the white paper before posting this nonsense. (http://www.sun.com/bigadmin/content/dtrace/dtrace_usenix.pdf for those who weren''t aware of it) So Chris: sounds like your plan is a good one. Thanks guys, Chip Bennett Laurus Technologies, Inc. Adam Leventhal wrote:>Hi Chip, > >A couple of points that need some clarification: > >The stop() action is synchronous (at least with respect to application >activity); the system() action, however, is processed along with traced data. >There''s no cont() action (obviously since a stopped process can''t hit any >probes where we could use such an action), but you can use ''system("prun %d", >pid)'' to effect something similar. > >Notice that if you do something like this: > >syscall::open:return >/pid == $target/ >{ > stop(); > system("prun %d", pid); >} > >you can be certain that while the application may, as you say, be ahead of >the information that''s been processed by the DTrace consumer, the processing >of the system action will take place after that information has been consumed. > >Adam > >On Thu, Jun 01, 2006 at 05:14:28PM -0500, Chip Bennett wrote: > > >>Chris, >> >>Quoting the DTrace guide: >> >>"The stop() action forces the process that fires the enabled probe to >>stop when it next >>leaves the kernel, as if stopped by a proc(4) action. The prun(1) >>utility may be used >>to resume a process that has been stopped by the stop() action. The >>stop() action >>can be used to stop a process at any DTrace probe point. This action can >>be used to >>capture a program in a particular state that would be difficult to >>achieve with a simple >>breakpoint, and then attach a traditional debugger like mdb(1) to the >>process. You can >>also use the gcore(1) utility to save the state of a stopped process in >>a core file for >>later analysis." >> >>As far as I can tell there is no "cont()" function in DTrace. But this >>way of getting mdb attached to the process bothers me. Here''s why: >>your DTrace program is a consumer on a 4M buffer. The DTrace probes are >>producing data into the same buffer. Because of the buffer, your >>application could be way ahead of what your DTrace program sees. You >>wouldn''t want it any other way, as it would severely impact the >>performance of the system. >> >>Assuming I have this right, how could you know the application process >>state at the point where your DTrace program issues the "stop" action. >>By the time the DTrace program sees the buffer data that indicates there >>was an "exec" of a new executable, that executable could have already >>stepped through a million instructions. >> >>If hate to disagree with the DTrace guide, but I don''t see how this can >>work. So, OK, what am I not seeing? :-) >> >>Chip Bennett >>Laurus Technologies, Inc. >> >>Chris Quenelle wrote: >> >> >> >>>Chip (and Rod Evans in private email) both suggested that I >>>use two different scripts for this. That approach seems >>>promising. >>> >>>I actually want to: >>> 1. find a specific process in a tree (the first matching one, for now) >>> 2. step this process forward until a certain point, then stop() it >>> >>>So my next avenue of attack will be to do step 1 in one dtrace >>>script, and stop the process usig stop(). Then use another dtrace script >>>to attach to the process and continue it until the interesting point. >>> >>>(At this point the process will be ready to attach to with a debugger). >>> >>>Is there a corresponding cont() command to undo a stop() command? >>>I would want to use that from the BEGIN clause in my dtrace script. >>>I can''t use /bin/prun because the process would run away, and I would >>>miss the dtrace event I''m looking for. >>> >>>--chris >>> >>> >>> >>_______________________________________________ >>dtrace-discuss mailing list >>dtrace-discuss at opensolaris.org >> >> > > >