dtrace discuss - Jan 2006 - dtrace and follow fork

I am trying to use dtrace to trace all sscanf calls.
I am able to use  pid provider for this.
 
 But my application forks off children at times to
handle requests.
 
 Is there a way I can stop the child process
immediately after it is  started so that  
 I can attach a pid provider to that and trace the
scanf calls in it?
   
 I have tried using the "create" probe but that did
not help.
 
 Attached is my test program and an attempt to use the
create probe.

Thanks and regards,
geeta



__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: create.d
URL:
<http://mail.opensolaris.org/pipermail/dtrace-discuss/attachments/20060111/1676782b/attachment.ksh>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: scanf.c
URL:
<http://mail.opensolaris.org/pipermail/dtrace-discuss/attachments/20060111/1676782b/attachment.c>

Hi Geeta,

When you say that the proc:::create probe didn''t help, can you explain
what
you mean?

I suggest using either the proc:::start or proc:::exec-success probes with
predicates using progenyof() to specify that you only want children of a
given process. Then use the stop() action to stop the process and the
system action to spawn another DTrace invocation.

Adam

On Wed, Jan 11, 2006 at 05:53:06PM -0800, Geeta S. Gharpure
wrote:
>  I am trying to use dtrace to trace all sscanf calls.
> I am able to use  pid provider for this.
>  
>  But my application forks off children at times to
> handle requests.
>  
>  Is there a way I can stop the child process
> immediately after it is  started so that  
>  I can attach a pid provider to that and trace the
> scanf calls in it?
>    
>  I have tried using the "create" probe but that did
> not help.
>  
>  Attached is my test program and an attempt to use the
> create probe.
> 
> Thanks and regards,
> geeta
> 
> 
> 
> __________________________________________________
> Do You Yahoo!?
> Tired of spam?  Yahoo! Mail has the best spam protection around 
> http://mail.yahoo.com 
Content-Description: 969363211-create.d
> proc:::create
> {
> 	printf("\npid = %d\t",args[0]->pr_pid);
> 	printf("pr_fname = %s\n",args[0]->pr_fname);
> 	
> }
> 
> proc:::start
> {
> 	printf("\n Spin start\n");
> 	system ("/usr/bin/sleep 10") ;
> 	printf("\n Spin end\n");
> 	
> }
Content-Description: 1712678508-scanf.c
> #include <stdio.h>
> #include <unistd.h>
> #include <sys/types.h>
> 
> int main
> (int argc,char *argv[])
> {
> 	pid_t cpid=0;
> 	char str [] = "Sample string";
> 	char *buf;
> 	printf ("Parent process\n");
> 	sleep (30);
> 	cpid = fork();
> 	if (cpid == 0)
> 	{
> 		printf ("Child process\n");
> 		sscanf (str,"%*s",buf);
> 		printf ("Child process exiting\n");
> 		exit(0);
> 	}
> 
> 	printf ("Parent process ending\n");
> 
> }
> _______________________________________________
> dtrace-discuss mailing list
> dtrace-discuss at opensolaris.org
-- 
Adam Leventhal, Solaris Kernel Development       http://blogs.sun.com/ahl

Or maybe, the question is "what the heck is a tcp function doing
in ip?"

I am trying to trace the behavior of a particular TCP connection.
I am on a pretty quiet box, so what I do is instrument tcp_mss_set
to capture the tcp_t structure pointer, and then trace all
function that begin with tcp_* and have a first argument that matches
that pointer. When I get a hit, I set a flag to get full fbt::: type
flowindent tracing and also print out a stack.

Now, the odd thing is that the stack I get is often like this:

  0  -> tcp_send_data
               ip`tcp_rput_data+0x318c
               ip`tcp_rput_data+0x14bc
               ip`squeue_enter+0x74
               ip`ip_tcp_input+0x8e0
               ip`ip_rput+0x6f4
               unix`putnext+0x218
               eri`eri_intr+0x43c
               pcisch`pci_intr_wrapper+0xb4
               unix`intr_thread+0x148

Notice that tcp_rput_data is shown as part of the ip module. Except
that it isn''t, it lives in tcp.c.  Further, notice that entering
tcp_rput_data did not trigger the tcp_* probe, even though it does
have the same tcp argument.

Any body have an idea what is going on?

-- 
blu

Quidquid latine dictum sit, altum sonatur.
----------------------------------------------------------------------
Brian Utterback - OP/N1 RPE, Sun Microsystems, Inc.
Ph:877-259-7345, Em:brian.utterback-at-ess-you-enn-dot-kom

Nevermind. All the tcp functions show up as part of ip, and unlike
other tcp functions, tcp_rput_data takes a pointer to a connp
struct as the first argument and not a pointer to a tcp_t.

Duh. I''ll go back to sleep now.

Brian Utterback wrote:
> Or maybe, the question is "what the heck is a tcp function doing
> in ip?"
> 
> I am trying to trace the behavior of a particular TCP connection.
> I am on a pretty quiet box, so what I do is instrument tcp_mss_set
> to capture the tcp_t structure pointer, and then trace all
> function that begin with tcp_* and have a first argument that matches
> that pointer. When I get a hit, I set a flag to get full fbt::: type
> flowindent tracing and also print out a stack.
> 
> Now, the odd thing is that the stack I get is often like this:
> 
>  0  -> tcp_send_data
>               ip`tcp_rput_data+0x318c
>               ip`tcp_rput_data+0x14bc
>               ip`squeue_enter+0x74
>               ip`ip_tcp_input+0x8e0
>               ip`ip_rput+0x6f4
>               unix`putnext+0x218
>               eri`eri_intr+0x43c
>               pcisch`pci_intr_wrapper+0xb4
>               unix`intr_thread+0x148
> 
> Notice that tcp_rput_data is shown as part of the ip module. Except
> that it isn''t, it lives in tcp.c.  Further, notice that entering
> tcp_rput_data did not trigger the tcp_* probe, even though it does
> have the same tcp argument.
> 
> Any body have an idea what is going on?
> 

-- 
blu

Quidquid latine dictum sit, altum sonatur.
----------------------------------------------------------------------
Brian Utterback - OP/N1 RPE, Sun Microsystems, Inc.
Ph:877-259-7345, Em:brian.utterback-at-ess-you-enn-dot-kom

>>>>> "Brian" == Brian Utterback <brian.utterback at
sun.com> writes:

    Brian> Or maybe, the question is "what the heck is a tcp function
doing
    Brian> in ip?"

FireEngine removed tcp as a module doing anything useful (well, it is still used
to support SNMP). Now ip and tcp is the same thing.

- Alexander Kolbasov

On Fri, Jan 13, 2006 at 01:48:26PM -0800, Alexander Kolbasov
wrote:
> >>>>> "Brian" == Brian Utterback
<brian.utterback at sun.com> writes:
> 
> 
>     Brian> Or maybe, the question is "what the heck is a tcp
function doing
>     Brian> in ip?"
> 
> FireEngine removed tcp as a module doing anything useful (well, it is still
used
> to support SNMP). Now ip and tcp is the same thing.
It truly is "TCP/IP" ;)

(Sorry, I couldn''t resist.  Back to normal programming now.)

Nico
--