dtrace discuss - Aug 2009 - putting a running app into trace mode

Suppose I have a USDT probe in Firefox and that I''m trying to catch  
the startup with a probe like this:

proc:::exec-success
/execname == "firefox-bin"/
{
	start = timestamp;
}

and stop tracing when Firefox hits this USDT probe:

mozilla:::main-entry
{
   exit(0);
}

How do I put the running firefox-bin into "trace mode" so that my USDT
probe fires?

	Thanks, Joel

---
fastest mac firefox!
http://wagerlabs.com

On Fri, Aug 28, 2009 at 3:30 PM, Joel Reymont<joelr1 at gmail.com>
wrote:
> Suppose I have a USDT probe in Firefox and that I''m trying to
catch the
> startup with a probe like this:
>
> proc:::exec-success
> /execname == "firefox-bin"/
> {
> ? ? ? ?start = timestamp;
> }
>
> and stop tracing when Firefox hits this USDT probe:
>
> mozilla:::main-entry
> {
> ?exit(0);
> }
>
> How do I put the running firefox-bin into "trace mode" so that my
USDT probe
> fires?
>
You can do this with two separate DTrace invocations.  The first
catches the exec of firefox-bin and fires off the second.  Something
like this for the first one:

proc:::exec-success
/ execname == "firefox-bin" /
{
       stop();
       system("/tmp/trace-firefox.d -p %d", pid);
}

This will stop firefox-bin just after the exec.  (Note that it needs
the destructive option, -w or "#pragma D option destructive".)
/tmp/trace-firefox.d does the tracing you want using the USDT probes
in firefox-bin.

Chad

Thanks Chad!

How do I pass the 2nd script as argument into the first, though?

	Thanks, Joel

On Aug 28, 2009, at 8:52 PM, Chad Mynhier wrote:
> You can do this with two separate DTrace invocations.  The first
> catches the exec of firefox-bin and fires off the second.  Something
> like this for the first one:
>
> proc:::exec-success
> / execname == "firefox-bin" /
> {
>       stop();
>       system("/tmp/trace-firefox.d -p %d", pid);
> }
---
fastest mac firefox!
http://wagerlabs.com

The system() action is printf()-like, so you could do something like this:

proc:::exec-success
/ execname == "firefox-bin" /
{
        stop();
        system("%s -p %d", $1, pid);
}

and pass in the name of the 2nd script as the first argument.

Chad

On Fri, Aug 28, 2009 at 3:54 PM, Joel Reymont<joelr1 at gmail.com>
wrote:
> Thanks Chad!
>
> How do I pass the 2nd script as argument into the first, though?
>
> ? ? ? ?Thanks, Joel
>
> On Aug 28, 2009, at 8:52 PM, Chad Mynhier wrote:
>
>> You can do this with two separate DTrace invocations. ?The first
>> catches the exec of firefox-bin and fires off the second. ?Something
>> like this for the first one:
>>
>> proc:::exec-success
>> / execname == "firefox-bin" /
>> {
>> ? ? ?stop();
>> ? ? ?system("/tmp/trace-firefox.d -p %d", pid);
>> }
>
> ---
> fastest mac firefox!
> http://wagerlabs.com
>
>
>
>
>

On Aug 28, 2009, at 8:52 PM, Chad Mynhier wrote:
> proc:::exec-success
> / execname == "firefox-bin" /
> {
>       stop();
>       system("/tmp/trace-firefox.d -p %d", pid);
> }

All the examples I have seen hardcode /tmp/trace-firefox.d.

How do I make it dynamic, though? For example, in

dtrace -s 1.d -s 2.d -s 3.d

How do i grab 2.d and 3.d in 1.d, assuming 1.d is the script with exec- 
success?

	Thanks, Joel

---
fastest mac firefox!
http://wagerlabs.com

On Fri, Aug 28, 2009 at 03:52:01PM -0400, Chad Mynhier
wrote:
> You can do this with two separate DTrace invocations.  The first
> catches the exec of firefox-bin and fires off the second.  Something
> like this for the first one:
> 
> proc:::exec-success
> / execname == "firefox-bin" /
> {
>        stop();
>        system("/tmp/trace-firefox.d -p %d", pid);
> }
> 
> This will stop firefox-bin just after the exec.  (Note that it needs
> the destructive option, -w or "#pragma D option destructive".)
> /tmp/trace-firefox.d does the tracing you want using the USDT probes
> in firefox-bin.
Don''t forget to have a system("prun $pid"); action in the
BEGIN probe of
the second script...

This is such a common idiom...  Yet there''s no obvious, safe way to
provide syntactic sugar, is there?  Hmmm, maybe there is.  Imagine a
pre-processor that separates probes for each process from a larger
script, generates the proc:::exec-success probe actions, and the BEGIN {
system("prun ..."); } probes.  Something like:

/*
 * Declare interest in doing some PID provider tracing of firefox-bin
 * progeny.
 */
#pragma trace-exec second /execname == "firefox-bin" &&
progenyof(pid)/

/* This probe will be used for the first process */
pid$pid:...

/* This probe will be used in the firefox-bin proc(s) */
pid$second:...

Could be handy.  Ideally only one instance of dtrace would be needed,
though one might ask for a separate instance in the trace-exec pragma.

Nico
--

I got it, actually.

#!/bin/bash

rest=""

for i in $*; do rest="$rest -s $i"; done

dtrace=''

inline string REST="''$rest''";

proc:::exec-success
/execname == "firefox-bin"/
{
   stop();
   system("dtrace -p %d %s", pid, REST);
   exit(0);
}
''

dtrace -wn "$dtrace"

---
fastest mac firefox!
http://wagerlabs.com

On Aug 28, 2009, at 9:44 PM, Nicolas Williams wrote:
> Don''t forget to have a system("prun $pid"); action in
the BEGIN
> probe of
> the second script...

There doesn''t seem to be a prun on Mac OSX.

---
fastest mac firefox!
http://wagerlabs.com

On Fri, Aug 28, 2009 at 4:44 PM, Nicolas
Williams<Nicolas.Williams at sun.com> wrote:
> On Fri, Aug 28, 2009 at 03:52:01PM -0400, Chad Mynhier wrote:
>> You can do this with two separate DTrace invocations. ?The first
>> catches the exec of firefox-bin and fires off the second. ?Something
>> like this for the first one:
>>
>> proc:::exec-success
>> / execname == "firefox-bin" /
>> {
>> ? ? ? ?stop();
>> ? ? ? ?system("/tmp/trace-firefox.d -p %d", pid);
>> }
>>
>> This will stop firefox-bin just after the exec. ?(Note that it needs
>> the destructive option, -w or "#pragma D option
destructive".)
>> /tmp/trace-firefox.d does the tracing you want using the USDT probes
>> in firefox-bin.
>
> 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.  Consider this
script, /tmp/foo.d:

#!/usr/sbin/dtrace -qws

proc:::exec-success
/ execname == "ls" /
{
        stop();
        system("%s -p %d", $1, pid);
}

and this script, /tmp/bar.d:

#!/usr/sbin/dtrace -qs

pid$target::main:entry
{
        printf("Entered main()\n");
        exit(0);
}

When I run these and run ls a couple of times in another shell, I see this:

x2200# /tmp/foo.d /tmp/bar.d
Entered main()

Entered main()

^C

x2200#

And the ls''s complete normally in the other shell.

Chad

On Fri, Aug 28, 2009 at 05:13:41PM -0400, Chad Mynhier
wrote:
> On Fri, Aug 28, 2009 at 4:44 PM, Nicolas
> Williams<Nicolas.Williams at 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.  Consider this
> script, /tmp/foo.d:
Is this new?  It''s very nice...  Thanks,

Nico
--

> > > 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.  Consider this
> > script, /tmp/foo.d:
> 
> Is this new?  It''s very nice...  Thanks,
I believe it''s an accidental "feature" that has been there
forever.

Adam

-- 
Adam Leventhal, Fishworks                     http://blogs.sun.com/ahl

On Aug 28, 2009, at 11:36 PM, Adam Leventhal wrote:
> I believe it''s an accidental "feature" that has been
there forever.

FYI, it doesn''t work this way on the Mac. I have to ''kill
-CONT
$target'' from the 1st script in my pipeline, otherwise I have to
''fg''
in ther terminal window where I launch the app that I''m tracing.

---
fastest mac firefox!
http://wagerlabs.com

Here''s my complete Mac solution. It misses the dynamic linking phase,  
I''m afraid, which is not something that ''dtrace -c
...'' was doing. It
does allow apps to run in their native environment, though, as opposed  
to as root.

I can launch it like this, for example, to stop once my USDT probe is  
fired in the Firefox main().

./d firefox-bin startup.d stop-main.d

or to figure out the time spent by Firefox on the CPU during the first  
10s of startup:

./d firefox-bin cpu.d stop-10s.d

d:

#!/bin/bash

progname=$1
shift

scripts="-s sigcont.d"

for i in $*; do scripts="$scripts -s $i"; done

opts="-Zqw -x dynvarsize=64m -x evaltime=exec"

dtrace=''

inline string progname="''$progname''";
inline string scripts="''$scripts''";
inline string opts="''$opts''";

proc:::exec-success
/execname == progname/
{
   stop();
   printf("dtrace %s -p %d %s\n", opts, pid, scripts);
   system("dtrace %s -p %d %s\n", opts, pid, scripts);
   exit(0);
}
''

sync && purge && dtrace $opts -n "$dtrace"
---

sigcont.d:

BEGIN
{
   printf("kill -CONT %d\n", $target);
   system("kill -CONT %d\n", $target);
}
---

All the scripts are up on Github [1] and I love building these chains  
of "lego blocks" in different permutations.

[1] http://github.com/wagerlabs/firefox-startup/tree/master

---
fastest mac firefox!
http://wagerlabs.com

I used to be able to stop tracing Safari once NSApplicationMain was  
entered. This was with ''dtrace -c...''. I''m no longer
able to do so
with exec-success, stop and attaching to the stopped process, e.g.

./d Safari startup.d stop-nsapp.d

where startup.d:

BEGIN
{
   start = timestamp;
}

END
{
   this->total = timestamp - start;
   printf("Total: %u.%06ums\n", this->total / 1000000,
this->total %
1000000);
}

and stop-nsapp.d:

pid$target::NSApplicationMain:entry
{
   exit(0);
}

Any suggestions on how to fix this?

	Thanks, Joel

---
fastest mac firefox!
http://wagerlabs.com