G''Day James, On Thu, 20 Jan 2005, James Dickens wrote:> i''m trying to write my first dtrace script apparently i bit off a bit > more than i can chew, i want to track io over sockets, i found yourI''ve been working on this for some time (networking by process) - so far I can only do it by turning on far too many probes, I''m trying to nail an elegant solution (almost there). I wouldn''t pick a networking topic as your first DTrace script!!> socketsize.d that gave me how to track writes, but i''m at a loss how > to track reads, frankly i don''t see how your write tracker works > because it uses a probe in a function that only takes two arguments > but you grab size of write via arg3?Yes, I''d like to know how I used arg3 as well. I often write scripts like this, #pragma D option flowindent fbt:sockfs:sotpi_recvmsg:entry { self->ok=1; } fbt:sockfs:sotpi_recvmsg:return { self->ok=0; } fbt::: /self->ok/ { printf("%12s %s:%s:%s:%s %5x %5x %5x %5x %5x %5x %5x %5x\n", execname,probeprov,probemod,probefunc,probename, arg0,arg1,arg2,arg3,arg4,arg5,arg6,arg7); } So I watch the 8 args from all functionss and spot things of interest, then match versus the prototype. With fbt:sockfs:so_update_attrs:entry I spotted arg3 had the byte count. Great. Later I read the prototype, socketvar.h:extern void so_update_attrs(struct sonode *, int); Hmm. Not sure why DTrace is pulling meaningful information for args that shouldn''t exist - but it was working reliably so I''ve left that mystery to investigate at a later date. At some point I''ll get stuck into the Solaris source and may find extra prototypes that aren''t in /usr/include/sys. (Oh! looks like you tried that already!) Or perhaps DTrace is reading memory addresses from a previous function that it didn''t clear. Whatever the reason, I imagine in the long term this will be done by a network provider and not fbt, so these scripts are rather temporary. no worries, Brendan> James Dickens[...]> > from src/src/uts/common/fs/sockfs/socksubr.c > > void > so_update_attrs(struct sonode *so, int flag) > > > >_______________________________________________ DTrace mailing list DTrace@opensolaris.org https://www.opensolaris.org/mailman/listinfo/dtrace
G''Day Max, Ok, that confirms that it is unreliable - I just tried it on sparc and it dosen''t work. Hmm. Either I forgot to check it on sparc before, or something changed in the builds. (I''ve always been suspicious about those socket*.d scripts, hence a version number of 0.50 - low confidence). I just rewrote it using the mib provider. It works fine on sparc now. http://www.brendangregg.com/DTrace/socketsize.d Brendan On Thu, 20 Jan 2005, Max Bruning wrote:> > Maybe arg3 is left over from a previously called function. > Have you tried the script on both sparc and x86 to see > if it works? > > max >_______________________________________________ DTrace mailing list DTrace@opensolaris.org https://www.opensolaris.org/mailman/listinfo/dtrace
I''ve had a similar problem tracing segmap_getmapflt(). The 2nd (or 3rd) arg is the size. On Sparc, I use arg[2] and arg[3] for the next argument. On x86, I find I need to use (long long)arg[2] and arg[4] for the next argument. (When I am finished with the script, I''ll post it...). max On Thursday, January 20, 2005, at 08:38 PM, Brendan Gregg wrote:> G''Day Max, > > Ok, that confirms that it is unreliable - I just tried it on sparc and > it > dosen''t work. Hmm. Either I forgot to check it on sparc before, or > something changed in the builds. (I''ve always been suspicious about > those > socket*.d scripts, hence a version number of 0.50 - low confidence). > > > I just rewrote it using the mib provider. It works fine on sparc now. > > http://www.brendangregg.com/DTrace/socketsize.d > > Brendan > > > > On Thu, 20 Jan 2005, Max Bruning wrote: > >> >> Maybe arg3 is left over from a previously called function. >> Have you tried the script on both sparc and x86 to see >> if it works? >> >> max >> > > > > >_______________________________________________ DTrace mailing list DTrace@opensolaris.org https://www.opensolaris.org/mailman/listinfo/dtrace
G''Day, On Thu, 20 Jan 2005, Max Bruning wrote:> Hi, > OK. So additional args to entry probes are documented by... > reading the source!!!? and asking some kernel guys???... So far I haven''t read the source as I''m writing DTrace scripts for a public website, and I don''t want to publish info I ought not to. When OpenSolaris really is open life will be a little easier. :)> OK. I can do that... > I just looked at the docs, and I don''t see it documented...On the public forum you can read the "DTrace watches ssh keystrokes" thread, where I explain determining the arguments by reading hex dumps for several hours. Jonathan Adams did a follow up post and explained how to do it in mdb. In one line! So... you can read hex dumps for several hours, or, you can use "funcion_name::nm -f ctype" from mdb. # mdb -k Loading modules: [ unix krtld genunix specfs dtrace ufs ip sctp usba fctl nca nfs audiosup random sppp sd crypto ptm ipc logindmux ] > socktpi_read::nm -f ctype C Type int (*)(struct vnode *, struct uio *, int, struct cred *, struct caller_context *) not to worry, I know more of mdb''s secrets now ;) Brendan _______________________________________________ DTrace mailing list DTrace@opensolaris.org https://www.opensolaris.org/mailman/listinfo/dtrace
Hi.
It looks to me like socketsnoop.d (also on Brendan''s page)
will do most of what you want. Specifically, the
socktpi_read trace. If you want to track the data
itself, you''ll need to trace calls to strread and kstrgetmsg.
I have a dtrace script that tracks strrput calls and prints out
the message data, but it is cumbersome to use (you need to
give it a vnode address for the stream head you want to snoop).
strrput is called by the downstream module (tcp/ip in the case of sockets) to
enqueue messages at the stream head. strread or
kstrgetmsg is used to retrieve enqueued messages.
Here is a dtrace script that traces (and prints) M_DATA messages
arriving on STREAMS heads. You give it a vnode address
as an argument. Try to use this with data you expect to be ascii.
Currently, there is no good way to print binary data in dtrace.
-------------------CUT HERE----------------------------
#!/usr/sbin/dtrace -qs
#pragma D option strsize=8192
BEGIN {
cvp = (struct vnode *)$1; /* you tell dtrace which vnode */
}
strrput:entry
/ args[0]->q_stream->sd_vnode == cvp &&
args[1]->b_datap->db_type == 0x00 / /* only M_DATA messages */
{
self->mp = args[1];
}
strrput:entry
/ args[1]->b_datap->db_type == 0x00 && self->mp != NULL /
{
printf("%*.*s", args[1]->b_wptr-args[1]->b_rptr,
args[1]->b_wptr-args[1]->b_rptr, (string)args[1]->b_rptr);
self->mp = self->mp->b_cont;
}
strrput:entry
/ args[1]->b_datap->db_type == 0x00 && self->mp != NULL /
{
printf("%*.*s", args[1]->b_wptr-args[1]->b_rptr,
args[1]->b_wptr-args[1]->b_rptr, (string)args[1]->b_rptr);
self->mp = self->mp->b_cont;
}
strrput:entry
/ args[1]->b_datap->db_type == 0x00 && self->mp != NULL /
{
printf("%*.*s", args[1]->b_wptr-args[1]->b_rptr,
args[1]->b_wptr-args[1]->b_rptr, (string)args[1]->b_rptr);
self->mp = self->mp->b_cont;
}
strrput:entry
/ args[1]->b_datap->db_type == 0x00 && self->mp != NULL /
{
printf("%*.*s", args[1]->b_wptr-args[1]->b_rptr,
args[1]->b_wptr-args[1]->b_rptr, (string)args[1]->b_rptr);
self->mp = self->mp->b_cont;
}
strrput:entry
/ args[1]->b_datap->db_type == 0x00 && self->mp != NULL /
{
printf("%*.*s", args[1]->b_wptr-args[1]->b_rptr,
args[1]->b_wptr-args[1]->b_rptr, (string)args[1]->b_rptr);
self->mp = self->mp->b_cont;
}
strrput:entry
/ args[1]->b_datap->db_type == 0x00 && self->mp != NULL /
{
printf("%*.*s", args[1]->b_wptr-args[1]->b_rptr,
args[1]->b_wptr-args[1]->b_rptr, (string)args[1]->b_rptr);
self->mp = self->mp->b_cont;
}
strrput:entry
/ args[1]->b_datap->db_type == 0x00 && self->mp != NULL /
{
printf("%*.*s", args[1]->b_wptr-args[1]->b_rptr,
args[1]->b_wptr-args[1]->b_rptr, (string)args[1]->b_rptr);
self->mp = self->mp->b_cont;
}
strrput:entry
/ args[1]->b_datap->db_type == 0x00 && self->mp != NULL /
{
printf("%*.*s", args[1]->b_wptr-args[1]->b_rptr,
args[1]->b_wptr-args[1]->b_rptr, (string)args[1]->b_rptr);
self->mp = self->mp->b_cont;
}
strrput:entry
/ args[1]->b_datap->db_type == 0x00 && self->mp != NULL /
{
printf("%*.*s", args[1]->b_wptr-args[1]->b_rptr,
args[1]->b_wptr-args[1]->b_rptr, (string)args[1]->b_rptr);
self->mp = self->mp->b_cont;
}
strrput:entry
/ args[1]->b_datap->db_type == 0x00 && self->mp != NULL /
{
printf("%*.*s", args[1]->b_wptr-args[1]->b_rptr,
args[1]->b_wptr-args[1]->b_rptr, (string)args[1]->b_rptr);
self->mp = self->mp->b_cont;
}
strclose:entry
/ args[0] == cvp /
{
exit(0);
}
------------------CUT HERE-------------------
To use this, you need 2 windows. In one window, start the
program you want to trace. For instance, telnet:
# telnet 192.168.2.102 (or whatever host...)
...
In the other window (on local machine):
# pfiles `pgrep telnet` <-- get fd for the socket you want to snoop
6444: /usr/bin/telnet
Current rlimit: 256 file descriptors
0: S_IFCHR mode:0620 dev:270,0 ino:12582942 uid:100 gid:7 rdev:24,13
O_RDWR|O_NDELAY
/devices/pseudo/pts@0:13
1: S_IFCHR mode:0620 dev:270,0 ino:12582942 uid:100 gid:7 rdev:24,13
O_RDWR|O_NDELAY
/devices/pseudo/pts@0:13
2: S_IFCHR mode:0620 dev:270,0 ino:12582942 uid:100 gid:7 rdev:24,13
O_RDWR|O_NDELAY
/devices/pseudo/pts@0:13
3: S_IFSOCK mode:0666 dev:276,0 ino:32025 uid:0 gid:0 size:0
O_RDWR|O_NDELAY
SOCK_STREAM
SO_OOBINLINE,SO_SNDBUF(49152),SO_RCVBUF(49640)
sockname: AF_INET 192.168.2.100 port: 40037
peername: AF_INET 192.168.2.102 port: 23
# mdb -k
mdb: no terminal data available for TERM=emacs
mdb: term init failed: command-line editing and prompt will not be available
::ps!grep telnet
R 6444 6031 6444 6444 100 0x42004000 d352aa40 telnet
d352aa40::walk file <-- walk open files for this proc
d5597018
d5597018
d5597018
d4fbd508 <-- from pfiles output, this is the file we want
d4fbd508::print file_t f_vnode
f_vnode = 0xd6a4ff00 <-- and here''s the vnode for the socket
$q
# ./strrput3.d 0xd6a4ff00 <-- now run the script
Everything displayed on the screen in the telnet window should show up
in the dtrace output.
max
On Thu, 2005-01-20 at 11:49, James Dickens wrote:> Hi
>
> i''m trying to write my first dtrace script apparently i bit off a
bit
> more than i can chew, i want to track io over sockets, i found your
> socketsize.d that gave me how to track writes, but i''m at a loss
how
> to track reads, frankly i don''t see how your write tracker works
> because it uses a probe in a function that only takes two arguments
> but you grab size of write via arg3?
>
> i would appreciate any hints on how to accomplish this task, and an
> explanation of how the args work if i''m missing something
>
>
> Thanks
>
> James Dickens
>
>
> information relied on:
>
> from socketsize.d
> /*
> ** Process Socket Write
> */
> fbt:sockfs:so_update_attrs:entry
> /arg1 == 1/
> {
> /* fetch details */
> this->size = arg3;
> cmd = (string)curpsinfo->pr_psargs;
>
> /* store details */
> @Size[pid,cmd] = quantize(this->size);
> }
>
> from src/src/uts/common/fs/sockfs/socksubr.c
>
> void
> so_update_attrs(struct sonode *so, int flag)
> _______________________________________________
> DTrace mailing list
> DTrace@opensolaris.org
> https://www.opensolaris.org/mailman/listinfo/dtrace
>
_______________________________________________
DTrace mailing list
DTrace@opensolaris.org
https://www.opensolaris.org/mailman/listinfo/dtrace
Maybe arg3 is left over from a previously called function. Have you tried the script on both sparc and x86 to see if it works? max> > Yes, I''d like to know how I used arg3 as well. > > I often write scripts like this, > > #pragma D option flowindent > fbt:sockfs:sotpi_recvmsg:entry { self->ok=1; } > fbt:sockfs:sotpi_recvmsg:return { self->ok=0; } > fbt::: > /self->ok/ > { > printf("%12s %s:%s:%s:%s %5x %5x %5x %5x %5x %5x %5x %5x\n", > execname,probeprov,probemod,probefunc,probename, > arg0,arg1,arg2,arg3,arg4,arg5,arg6,arg7); > } > > So I watch the 8 args from all functionss and spot things of interest, > then match versus the prototype. With fbt:sockfs:so_update_attrs:entry I > spotted arg3 had the byte count. Great. Later I read the prototype, > > socketvar.h:extern void so_update_attrs(struct sonode *, int); > > Hmm. Not sure why DTrace is pulling meaningful information for args that > shouldn''t exist - but it was working reliably so I''ve left that mystery to > investigate at a later date. > > At some point I''ll get stuck into the Solaris source and may find extra > prototypes that aren''t in /usr/include/sys. (Oh! looks like you tried that > already!) Or perhaps DTrace is reading memory addresses from a previous > function that it didn''t clear. > > Whatever the reason, I imagine in the long term this will be done by a > network provider and not fbt, so these scripts are rather temporary. > > no worries, > > Brendan > > > > James Dickens > [...] > > > > from src/src/uts/common/fs/sockfs/socksubr.c > > > > void > > so_update_attrs(struct sonode *so, int flag) > > > > > > > > > > _______________________________________________ > DTrace mailing list > DTrace@opensolaris.org > https://www.opensolaris.org/mailman/listinfo/dtrace >_______________________________________________ DTrace mailing list DTrace@opensolaris.org https://www.opensolaris.org/mailman/listinfo/dtrace
Hi Okay i solved the problem it wasn''t as easy as it looks, just damm glad i had the source, and the help of a couple solaris kernel team members, thanks guys.. there names are in the file... James Dickens see atached file for how it was done On Thu, 20 Jan 2005 16:39:22 -0800, Max Bruning <max@bruningsystems.com> wrote:> > Maybe arg3 is left over from a previously called function. > Have you tried the script on both sparc and x86 to see > if it works? > > max > > > > > Yes, I''d like to know how I used arg3 as well. > > > > I often write scripts like this, > > > > #pragma D option flowindent > > fbt:sockfs:sotpi_recvmsg:entry { self->ok=1; } > > fbt:sockfs:sotpi_recvmsg:return { self->ok=0; } > > fbt::: > > /self->ok/ > > { > > printf("%12s %s:%s:%s:%s %5x %5x %5x %5x %5x %5x %5x %5x\n", > > execname,probeprov,probemod,probefunc,probename, > > arg0,arg1,arg2,arg3,arg4,arg5,arg6,arg7); > > } > > > > So I watch the 8 args from all functionss and spot things of interest, > > then match versus the prototype. With fbt:sockfs:so_update_attrs:entry I > > spotted arg3 had the byte count. Great. Later I read the prototype, > > > > socketvar.h:extern void so_update_attrs(struct sonode *, int); > > > > Hmm. Not sure why DTrace is pulling meaningful information for args that > > shouldn''t exist - but it was working reliably so I''ve left that mystery to > > investigate at a later date. > > > > At some point I''ll get stuck into the Solaris source and may find extra > > prototypes that aren''t in /usr/include/sys. (Oh! looks like you tried that > > already!) Or perhaps DTrace is reading memory addresses from a previous > > function that it didn''t clear. > > > > Whatever the reason, I imagine in the long term this will be done by a > > network provider and not fbt, so these scripts are rather temporary. > > > > no worries, > > > > Brendan > > > > > > > James Dickens > > [...] > > > > > > from src/src/uts/common/fs/sockfs/socksubr.c > > > > > > void > > > so_update_attrs(struct sonode *so, int flag) > > > > > > > > > > > > > > > > _______________________________________________ > > DTrace mailing list > > DTrace@opensolaris.org > > https://www.opensolaris.org/mailman/listinfo/dtrace > > >-------------- next part -------------- A non-text attachment was scrubbed... Name: socket_io Type: application/octet-stream Size: 949 bytes Desc: not available Url : http://mail.opensolaris.org/pipermail/dtrace-discuss/attachments/20050120/3b8083a9/socket_io.obj -------------- next part -------------- _______________________________________________ DTrace mailing list DTrace@opensolaris.org https://www.opensolaris.org/mailman/listinfo/dtrace
Hi, OK. So additional args to entry probes are documented by... reading the source!!!? and asking some kernel guys??? OK. I can do that... I just looked at the docs, and I don''t see it documented... Also, I don''t see any names in the file. max On Thursday, January 20, 2005, at 08:04 PM, James Dickens wrote:> Hi > > Okay i solved the problem it wasn''t as easy as it looks, just damm > glad i had the source, and the help of a couple solaris kernel team > members, thanks guys.. there names are in the file... > > > James Dickens > > see atached file for how it was done > > > > > On Thu, 20 Jan 2005 16:39:22 -0800, Max Bruning > <max@bruningsystems.com> wrote: >> >> Maybe arg3 is left over from a previously called function. >> Have you tried the script on both sparc and x86 to see >> if it works? >> >> max >> >>> >>> Yes, I''d like to know how I used arg3 as well. >>> >>> I often write scripts like this, >>> >>> #pragma D option flowindent >>> fbt:sockfs:sotpi_recvmsg:entry { self->ok=1; } >>> fbt:sockfs:sotpi_recvmsg:return { self->ok=0; } >>> fbt::: >>> /self->ok/ >>> { >>> printf("%12s %s:%s:%s:%s %5x %5x %5x %5x %5x %5x %5x %5x\n", >>> execname,probeprov,probemod,probefunc,probename, >>> arg0,arg1,arg2,arg3,arg4,arg5,arg6,arg7); >>> } >>> >>> So I watch the 8 args from all functionss and spot things of >>> interest, >>> then match versus the prototype. With >>> fbt:sockfs:so_update_attrs:entry I >>> spotted arg3 had the byte count. Great. Later I read the prototype, >>> >>> socketvar.h:extern void so_update_attrs(struct sonode *, int); >>> >>> Hmm. Not sure why DTrace is pulling meaningful information for args >>> that >>> shouldn''t exist - but it was working reliably so I''ve left that >>> mystery to >>> investigate at a later date. >>> >>> At some point I''ll get stuck into the Solaris source and may find >>> extra >>> prototypes that aren''t in /usr/include/sys. (Oh! looks like you >>> tried that >>> already!) Or perhaps DTrace is reading memory addresses from a >>> previous >>> function that it didn''t clear. >>> >>> Whatever the reason, I imagine in the long term this will be done by >>> a >>> network provider and not fbt, so these scripts are rather temporary. >>> >>> no worries, >>> >>> Brendan >>> >>> >>>> James Dickens >>> [...] >>>> >>>> from src/src/uts/common/fs/sockfs/socksubr.c >>>> >>>> void >>>> so_update_attrs(struct sonode *so, int flag) >>>> >>>> >>>> >>>> >>> >>> _______________________________________________ >>> DTrace mailing list >>> DTrace@opensolaris.org >>> https://www.opensolaris.org/mailman/listinfo/dtrace >>> >> > <socket_io>_______________________________________________ DTrace mailing list DTrace@opensolaris.org https://www.opensolaris.org/mailman/listinfo/dtrace
sorry bone head mistake.... wrong file got attached this one works On Thu, 20 Jan 2005 22:04:40 -0600, James Dickens <jamesd.wi@gmail.com> wrote:> Hi > > Okay i solved the problem it wasn''t as easy as it looks, just damm > glad i had the source, and the help of a couple solaris kernel team > members, thanks guys.. there names are in the file... > > James Dickens > > see atached file for how it was done > > > On Thu, 20 Jan 2005 16:39:22 -0800, Max Bruning <max@bruningsystems.com> wrote: > > > > Maybe arg3 is left over from a previously called function. > > Have you tried the script on both sparc and x86 to see > > if it works? > > > > max > > > > > > > > Yes, I''d like to know how I used arg3 as well. > > > > > > I often write scripts like this, > > > > > > #pragma D option flowindent > > > fbt:sockfs:sotpi_recvmsg:entry { self->ok=1; } > > > fbt:sockfs:sotpi_recvmsg:return { self->ok=0; } > > > fbt::: > > > /self->ok/ > > > { > > > printf("%12s %s:%s:%s:%s %5x %5x %5x %5x %5x %5x %5x %5x\n", > > > execname,probeprov,probemod,probefunc,probename, > > > arg0,arg1,arg2,arg3,arg4,arg5,arg6,arg7); > > > } > > > > > > So I watch the 8 args from all functionss and spot things of interest, > > > then match versus the prototype. With fbt:sockfs:so_update_attrs:entry I > > > spotted arg3 had the byte count. Great. Later I read the prototype, > > > > > > socketvar.h:extern void so_update_attrs(struct sonode *, int); > > > > > > Hmm. Not sure why DTrace is pulling meaningful information for args that > > > shouldn''t exist - but it was working reliably so I''ve left that mystery to > > > investigate at a later date. > > > > > > At some point I''ll get stuck into the Solaris source and may find extra > > > prototypes that aren''t in /usr/include/sys. (Oh! looks like you tried that > > > already!) Or perhaps DTrace is reading memory addresses from a previous > > > function that it didn''t clear. > > > > > > Whatever the reason, I imagine in the long term this will be done by a > > > network provider and not fbt, so these scripts are rather temporary. > > > > > > no worries, > > > > > > Brendan > > > > > > > > > > James Dickens > > > [...] > > > > > > > > from src/src/uts/common/fs/sockfs/socksubr.c > > > > > > > > void > > > > so_update_attrs(struct sonode *so, int flag) > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > DTrace mailing list > > > DTrace@opensolaris.org > > > https://www.opensolaris.org/mailman/listinfo/dtrace > > > > > > > >-------------- next part -------------- A non-text attachment was scrubbed... Name: socket_io.d Type: application/octet-stream Size: 1400 bytes Desc: not available Url : http://mail.opensolaris.org/pipermail/dtrace-discuss/attachments/20050120/4900567d/socket_io.obj -------------- next part -------------- _______________________________________________ DTrace mailing list DTrace@opensolaris.org https://www.opensolaris.org/mailman/listinfo/dtrace
Probably the mib or io provider is the right thing to use for most of the io based tracing. Its just more interesting to trace the calls that are doing the work;-) max On Thursday, January 20, 2005, at 09:10 PM, Max Bruning wrote:> > I''ve had a similar problem tracing segmap_getmapflt(). > The 2nd (or 3rd) arg is the size. On Sparc, I use arg[2] and arg[3] > for the next argument. On x86, I find I need to use (long long)arg[2] > and arg[4] for the next argument. (When I am finished with the script, > I''ll post it...). > > max > > On Thursday, January 20, 2005, at 08:38 PM, Brendan Gregg wrote: > >> G''Day Max, >> >> Ok, that confirms that it is unreliable - I just tried it on sparc >> and it >> dosen''t work. Hmm. Either I forgot to check it on sparc before, or >> something changed in the builds. (I''ve always been suspicious about >> those >> socket*.d scripts, hence a version number of 0.50 - low confidence). >> >> >> I just rewrote it using the mib provider. It works fine on sparc now. >> >> http://www.brendangregg.com/DTrace/socketsize.d >> >> Brendan >> >> >> >> On Thu, 20 Jan 2005, Max Bruning wrote: >> >>> >>> Maybe arg3 is left over from a previously called function. >>> Have you tried the script on both sparc and x86 to see >>> if it works? >>> >>> max >>> >> >> >> >> >> > >_______________________________________________ DTrace mailing list DTrace@opensolaris.org https://www.opensolaris.org/mailman/listinfo/dtrace
okay finnal fix of the night.... i''m tired... fixed a typo,. a cleaned up memory... like a good little programmer good night James On Thu, 20 Jan 2005 23:22:33 -0600, James Dickens <jamesd.wi@gmail.com> wrote:> sorry bone head mistake.... wrong file got attached this one works > > > On Thu, 20 Jan 2005 22:04:40 -0600, James Dickens <jamesd.wi@gmail.com> wrote: > > Hi > > > > Okay i solved the problem it wasn''t as easy as it looks, just damm > > glad i had the source, and the help of a couple solaris kernel team > > members, thanks guys.. there names are in the file... > > > > James Dickens > > > > see atached file for how it was done > > > > > > On Thu, 20 Jan 2005 16:39:22 -0800, Max Bruning <max@bruningsystems.com> wrote: > > > > > > Maybe arg3 is left over from a previously called function. > > > Have you tried the script on both sparc and x86 to see > > > if it works? > > > > > > max > > > > > > > > > > > Yes, I''d like to know how I used arg3 as well. > > > > > > > > I often write scripts like this, > > > > > > > > #pragma D option flowindent > > > > fbt:sockfs:sotpi_recvmsg:entry { self->ok=1; } > > > > fbt:sockfs:sotpi_recvmsg:return { self->ok=0; } > > > > fbt::: > > > > /self->ok/ > > > > { > > > > printf("%12s %s:%s:%s:%s %5x %5x %5x %5x %5x %5x %5x %5x\n", > > > > execname,probeprov,probemod,probefunc,probename, > > > > arg0,arg1,arg2,arg3,arg4,arg5,arg6,arg7); > > > > } > > > > > > > > So I watch the 8 args from all functionss and spot things of interest, > > > > then match versus the prototype. With fbt:sockfs:so_update_attrs:entry I > > > > spotted arg3 had the byte count. Great. Later I read the prototype, > > > > > > > > socketvar.h:extern void so_update_attrs(struct sonode *, int); > > > > > > > > Hmm. Not sure why DTrace is pulling meaningful information for args that > > > > shouldn''t exist - but it was working reliably so I''ve left that mystery to > > > > investigate at a later date. > > > > > > > > At some point I''ll get stuck into the Solaris source and may find extra > > > > prototypes that aren''t in /usr/include/sys. (Oh! looks like you tried that > > > > already!) Or perhaps DTrace is reading memory addresses from a previous > > > > function that it didn''t clear. > > > > > > > > Whatever the reason, I imagine in the long term this will be done by a > > > > network provider and not fbt, so these scripts are rather temporary. > > > > > > > > no worries, > > > > > > > > Brendan > > > > > > > > > > > > > James Dickens > > > > [...] > > > > > > > > > > from src/src/uts/common/fs/sockfs/socksubr.c > > > > > > > > > > void > > > > > so_update_attrs(struct sonode *so, int flag) > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > DTrace mailing list > > > > DTrace@opensolaris.org > > > > https://www.opensolaris.org/mailman/listinfo/dtrace > > > > > > > > > > > > > > > >-------------- next part -------------- A non-text attachment was scrubbed... Name: socket_io.d Type: application/octet-stream Size: 1402 bytes Desc: not available Url : http://mail.opensolaris.org/pipermail/dtrace-discuss/attachments/20050120/12a3b030/socket_io.obj -------------- next part -------------- _______________________________________________ DTrace mailing list DTrace@opensolaris.org https://www.opensolaris.org/mailman/listinfo/dtrace
On Thu, 20 Jan 2005, Max Bruning wrote:> Probably the mib or io provider is the right thing to use for most of > the io based tracing. Its just more interesting to trace the calls > that are > doing the work;-)I like your attitude. It''s even more interesting to read probe hex dumps. honest! ;) Brendan _______________________________________________ DTrace mailing list DTrace@opensolaris.org https://www.opensolaris.org/mailman/listinfo/dtrace
G''Day James,
Walking through those structs look quite nicely done. :)
I''m a little cautious about this though,
fbt:sockfs:socktpi_read:entry
/uid == 1000 /
(I assume 1000 is the UID for the user you''d like to trace).
This probe will only fire if the proc on the CPU has a UID of 1000, ie the
process you are interested in tracing. So, the process that is doing a
socket read needs to be on the CPU during this socktpi_read:entry call.
Here I trace the execname for the same call, while I send telnet packets,
# dtrace -n ''fbt:sockfs:socktpi_read:entry { trace(execname);
}''
dtrace: description ''fbt:sockfs:socktpi_read:entry '' matched
1 probe
CPU ID FUNCTION:NAME
0 19191 socktpi_read:entry Xsun
0 19191 socktpi_read:entry Xsun
0 19191 socktpi_read:entry Xsun
0 19191 socktpi_read:entry Xsun
0 19191 socktpi_read:entry Xsun
0 19191 socktpi_read:entry Xsun
[...]
However telnet is not caught.
What I think is happening is that the packet arrives asynchronously, so
we can''t guarantee that the correct process is on the CPU (here it is
incorrectly identifying Xsun). Sometimes it does work, sometimes not,
depending on scheduling. (seems ssh is picked up a lot more correctly than
telnet).
Either that or inetd/in.telnetd does something different strange after
connection to avoid using socktpi_read:entry....
It''s the asynchronous problem that''s had me working on this
for some time
now. I''m writing scripts to associate the asynchronous read with the
proc
completing the syscall read..
Any insight on what happens is appreciated! I''m slowly figuring this
out
with loads of DTrace.
cheers,
Brendan
On Thu, 20 Jan 2005, James Dickens wrote:
> okay finnal fix of the night.... i''m tired...
>
> fixed a typo,.
> a cleaned up memory... like a good little programmer
>
>
> good night
>
> James
>
>
>
> On Thu, 20 Jan 2005 23:22:33 -0600, James Dickens
<jamesd.wi@gmail.com> wrote:
> > sorry bone head mistake.... wrong file got attached this one works
> >
> >
> > On Thu, 20 Jan 2005 22:04:40 -0600, James Dickens
<jamesd.wi@gmail.com> wrote:
> > > Hi
> > >
> > > Okay i solved the problem it wasn''t as easy as it looks,
just damm
> > > glad i had the source, and the help of a couple solaris kernel
team
> > > members, thanks guys.. there names are in the file...
> > >
> > > James Dickens
> > >
> > > see atached file for how it was done
> > >
> > >
> > > On Thu, 20 Jan 2005 16:39:22 -0800, Max Bruning
<max@bruningsystems.com> wrote:
> > > >
> > > > Maybe arg3 is left over from a previously called function.
> > > > Have you tried the script on both sparc and x86 to see
> > > > if it works?
> > > >
> > > > max
> > > >
> > > > >
> > > > > Yes, I''d like to know how I used arg3 as well.
> > > > >
> > > > > I often write scripts like this,
> > > > >
> > > > > #pragma D option flowindent
> > > > > fbt:sockfs:sotpi_recvmsg:entry { self->ok=1; }
> > > > > fbt:sockfs:sotpi_recvmsg:return { self->ok=0; }
> > > > > fbt:::
> > > > > /self->ok/
> > > > > {
> > > > > printf("%12s %s:%s:%s:%s %5x %5x %5x %5x
%5x %5x %5x %5x\n",
> > > > >
execname,probeprov,probemod,probefunc,probename,
> > > > > arg0,arg1,arg2,arg3,arg4,arg5,arg6,arg7);
> > > > > }
> > > > >
> > > > > So I watch the 8 args from all functionss and spot
things of interest,
> > > > > then match versus the prototype. With
fbt:sockfs:so_update_attrs:entry I
> > > > > spotted arg3 had the byte count. Great. Later I read
the prototype,
> > > > >
> > > > > socketvar.h:extern void so_update_attrs(struct sonode
*, int);
> > > > >
> > > > > Hmm. Not sure why DTrace is pulling meaningful
information for args that
> > > > > shouldn''t exist - but it was working reliably
so I''ve left that mystery to
> > > > > investigate at a later date.
> > > > >
> > > > > At some point I''ll get stuck into the Solaris
source and may find extra
> > > > > prototypes that aren''t in /usr/include/sys.
(Oh! looks like you tried that
> > > > > already!) Or perhaps DTrace is reading memory addresses
from a previous
> > > > > function that it didn''t clear.
> > > > >
> > > > > Whatever the reason, I imagine in the long term this
will be done by a
> > > > > network provider and not fbt, so these scripts are
rather temporary.
> > > > >
> > > > > no worries,
> > > > >
> > > > > Brendan
> > > > >
> > > > >
> > > > > > James Dickens
> > > > > [...]
> > > > > >
> > > > > > from src/src/uts/common/fs/sockfs/socksubr.c
> > > > > >
> > > > > > void
> > > > > > so_update_attrs(struct sonode *so, int flag)
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > >
> > > > > _______________________________________________
> > > > > DTrace mailing list
> > > > > DTrace@opensolaris.org
> > > > > https://www.opensolaris.org/mailman/listinfo/dtrace
> > > > >
> > > >
> > >
> > >
> > >
> >
> >
> >
>
_______________________________________________
DTrace mailing list
DTrace@opensolaris.org
https://www.opensolaris.org/mailman/listinfo/dtrace
Hi
i''m trying to write my first dtrace script apparently i bit off a bit
more than i can chew, i want to track io over sockets, i found your
socketsize.d that gave me how to track writes, but i''m at a loss how
to track reads, frankly i don''t see how your write tracker works
because it uses a probe in a function that only takes two arguments
but you grab size of write via arg3?
i would appreciate any hints on how to accomplish this task, and an
explanation of how the args work if i''m missing something
Thanks
James Dickens
information relied on:
from socketsize.d
/*
** Process Socket Write
*/
fbt:sockfs:so_update_attrs:entry
/arg1 == 1/
{
/* fetch details */
this->size = arg3;
cmd = (string)curpsinfo->pr_psargs;
/* store details */
@Size[pid,cmd] = quantize(this->size);
}
from src/src/uts/common/fs/sockfs/socksubr.c
void
so_update_attrs(struct sonode *so, int flag)
_______________________________________________
DTrace mailing list
DTrace@opensolaris.org
https://www.opensolaris.org/mailman/listinfo/dtrace