DTracers, We''re a bit ashamed at how out of date the once lauded documentation is becoming, and, though we still haven''t updated the docs, I put together a DTrace community page that identifies some of the notable changes since the initial release of Solaris 10 as well as every DTrace-related putback. http://www.opensolaris.org/os/community/dtrace/ChangeLog/ As noted on that page, Solaris 10 6/06 contains everything up to and including the changes in snv_22. Another cut is being prepared which will bring Solaris 10 up to build 51 or so. Adam -- Adam Leventhal, Solaris Kernel Development http://blogs.sun.com/ahl
Adam Leventhal wrote:> DTracers, > > We''re a bit ashamed at how out of date the once lauded documentation is > becoming, and, though we still haven''t updated the docs, I put together > a DTrace community page that identifies some of the notable changes since > the initial release of Solaris 10 as well as every DTrace-related putback. > > http://www.opensolaris.org/os/community/dtrace/ChangeLog/ > > As noted on that page, Solaris 10 6/06 contains everything up to and > including the changes in snv_22. Another cut is being prepared which will > bring Solaris 10 up to build 51 or so. > > Adam >Just to add a little more detail: Solaris 10 Update 1 (0705) includes all the bugs integrated in snv_17 or earlier except: snv_17: 6276979 6278983 snv_16: 6267117 snv_15: 6259805 snv_11: 6237196 snv_10: 6216776 snv_09: 6197606 And in addition, includes these bug fixes from subsequent snv builds: snv_26: 6334302 snv_22: 6303188 6304654 6272865 snv_21: 6275414 6282291 6303053 Solaris 10 Update 2 (0606) includes all bug fixes included in update 1, still missing the same exception list, except 6237196 is now included. In addition, the following bug fixes are included: snv_38: 6405662 PSARC 2006/196 DTrace Filesystem Info Provider snv_23: 6315039 As much as it pains me to say this, as near as I can tell, that is it, there are no other fixes from the Nevada dtrace bug fix list that made it into Solaris 10 Update 2 (0606). Sorry Adam, I think you are wrong, as much as I had hoped you were right. -- blu "The genius of you Americans is that you never make clear-cut stupid moves, only complicated stupid moves which make us wonder at the possibility that there may be something to them which we are missing." - Gamal Abdel Nasser ---------------------------------------------------------------------- Brian Utterback - Solaris RPE, Sun Microsystems, Inc. Ph:877-259-7345, Em:brian.utterback-at-ess-you-enn-dot-kom
Thanks for the correction, Brian. I forgot that we had taking snv_17 with some additions for the big update 1 (7/05) putback. Adam On Fri, Nov 03, 2006 at 10:06:16AM -0500, Brian Utterback wrote:> Adam Leventhal wrote: > >DTracers, > > > >We''re a bit ashamed at how out of date the once lauded documentation is > >becoming, and, though we still haven''t updated the docs, I put together > >a DTrace community page that identifies some of the notable changes since > >the initial release of Solaris 10 as well as every DTrace-related putback. > > > > http://www.opensolaris.org/os/community/dtrace/ChangeLog/ > > > >As noted on that page, Solaris 10 6/06 contains everything up to and > >including the changes in snv_22. Another cut is being prepared which will > >bring Solaris 10 up to build 51 or so. > > > >Adam > > > > Just to add a little more detail: > > Solaris 10 Update 1 (0705) includes all the bugs integrated > in snv_17 or earlier except: > > snv_17: 6276979 > 6278983 > snv_16: 6267117 > snv_15: 6259805 > snv_11: 6237196 > snv_10: 6216776 > snv_09: 6197606 > > And in addition, includes these bug fixes from subsequent snv builds: > > snv_26: 6334302 > snv_22: 6303188 > 6304654 > 6272865 > snv_21: 6275414 > 6282291 > 6303053 > > Solaris 10 Update 2 (0606) includes all bug fixes included in > update 1, still missing the same exception list, except 6237196 is now > included. In addition, the following bug fixes are included: > > snv_38: 6405662 PSARC 2006/196 DTrace Filesystem Info Provider > snv_23: 6315039 > > As much as it pains me to say this, as near as I can tell, that is > it, there are no other fixes from the Nevada dtrace bug fix > list that made it into Solaris 10 Update 2 (0606). Sorry Adam, > I think you are wrong, as much as I had hoped you were right. > > -- > blu > > "The genius of you Americans is that you never make clear-cut stupid > moves, only complicated stupid moves which make us wonder at the > possibility that there may be something to them which we are missing." > - Gamal Abdel Nasser > ---------------------------------------------------------------------- > Brian Utterback - Solaris RPE, Sun Microsystems, Inc. > Ph:877-259-7345, Em:brian.utterback-at-ess-you-enn-dot-kom-- Adam Leventhal, Solaris Kernel Development http://blogs.sun.com/ahl
CHIAN-PHON LIN
2006-Nov-06 22:10 UTC
[dtrace-discuss] Fail to trace specific module in pid provider in snv_51a
Hi,
Dtrace in Solaris Nevada snv_51a was not able to
trace specific module such as libc if I run usr.d and
subsequent cmd.d and mod.d through stop() and prun
sequence etc.. However, if I change "pid$1:libc::entry"
to "pid$1:::entry" in mod.d, then libc can be traced.
This behaviour is different from previous OS.
In previous OS, libc can be traced with "pid$1:libc::entry".
In this example, I simply tried to trace libc
when "pwd" is executed. Below are 3 D-programs and
procedures to reproduce this problem.
*********************** usr.d *************************
#!/usr/sbin/dtrace -s
#pragma D option quiet
#pragma D option destructive
proc:genunix:exec_common:exec-success
/execname == "pwd"/
{
stop();
system("./cmd.d %d &", pid);
}
*********************** cmd.d *************************
#!/usr/sbin/dtrace -Zqs
#pragma D option destructive
BEGIN
{
system("prun %d", $1);
}
pid$1::_start:entry
/!progenyof($pid)/
{
stop();
system("./mod.d %d > d.out &", $1);
}
fbt:genunix:proc_exit:entry
/pid == $1/
{
exit(0);
}
*********************** mod.d *************************
#!/usr/sbin/dtrace -Zqs
#pragma D option destructive
BEGIN
{
system("prun %d", $1);
}
pid$1:libc::entry
{
@funcs[probemod, probefunc] = count();
}
fbt:genunix:proc_exit:entry
/pid == $1/
{
exit(0);
}
END
{
printa(@funcs);
}
***************** RUN usr.d and pwd *******************
% usr.d &
[1] 1309
% pwd
/var/tmp
% grep libc d.out | head
%
**** RUN usr.d and pwd after deleting libc in mod.d ***
% diff mod.d.old mod.d
7c7
< pid$1:libc::entry
---
> pid$1:::entry
%
% kill -9 1309
% usr.d &
[1] 1379
% pwd
/var/tmp
% grep libc d.out | head
libc.so.1 _cleanup 1
libc.so.1 _exithandle 1
libc.so.1 _fflush_l_iops 1
libc.so.1 _fflush_u 1
libc.so.1 _getfp 1
libc.so.1 _syscall6 1
libc.so.1 _write 1
libc.so.1 exit 1
libc.so.1 fflush 1
libc.so.1 getcwd 1
%
*********************** OS ******************************
% cat /etc/release
Solaris Nevada snv_51a SPARC
Copyright 2006 Sun Microsystems, Inc. All Rights Reserved.
Use is subject to license terms.
Assembled 27 October 2006
% uname -a
SunOS ctech104 5.11 snv_51 sun4u sparc SUNW,Serverblade1
%
--
************************************************
* C P Lin, Common Technology Project Lead. *
* Sun Microsystems Inc. *
* E-Mail: c.lin at sun.com *
* Address: 4150 Network Circle, M/S UMPK12-330 *
* Santa Clara, CA 95054 *
* Phone: 650/352-4967 Fax: 650/786-7816 *
************************************************
Adam Leventhal
2006-Nov-07 16:18 UTC
[dtrace-discuss] Fail to trace specific module in pid provider in snv_51a
The actual name of the probe is ''pid123:libc.so.1:malloc:entry'' (for example), rather than ''pid123:libc:malloc:entry''. We automatically change ''libc'' to ''libc.so.1'' if the library exists, but if you use the -Z flag and there''s nothing that matches the library name, we can''t make that change -- we don''t know, for eaxmple, if ''libc'' is a stand-alone module that''s going to be loaded or if it''s going to be ''libc.so.2'' or whatever. You can solve your problem by specifying the full library name. Adam On Mon, Nov 06, 2006 at 02:10:15PM -0800, CHIAN-PHON LIN wrote:> Hi, > > Dtrace in Solaris Nevada snv_51a was not able to > trace specific module such as libc if I run usr.d and > subsequent cmd.d and mod.d through stop() and prun > sequence etc.. However, if I change "pid$1:libc::entry" > to "pid$1:::entry" in mod.d, then libc can be traced. > This behaviour is different from previous OS. > In previous OS, libc can be traced with "pid$1:libc::entry". > In this example, I simply tried to trace libc > when "pwd" is executed. Below are 3 D-programs and > procedures to reproduce this problem. > > *********************** usr.d ************************* > #!/usr/sbin/dtrace -s > #pragma D option quiet > #pragma D option destructive > proc:genunix:exec_common:exec-success > /execname == "pwd"/ > { > stop(); > system("./cmd.d %d &", pid); > } > *********************** cmd.d ************************* > #!/usr/sbin/dtrace -Zqs > #pragma D option destructive > BEGIN > { > system("prun %d", $1); > } > pid$1::_start:entry > /!progenyof($pid)/ > { > stop(); > system("./mod.d %d > d.out &", $1); > } > fbt:genunix:proc_exit:entry > /pid == $1/ > { > exit(0); > } > *********************** mod.d ************************* > #!/usr/sbin/dtrace -Zqs > #pragma D option destructive > BEGIN > { > system("prun %d", $1); > } > pid$1:libc::entry > { > @funcs[probemod, probefunc] = count(); > } > fbt:genunix:proc_exit:entry > /pid == $1/ > { > exit(0); > } > END > { > printa(@funcs); > } > > ***************** RUN usr.d and pwd ******************* > % usr.d & > [1] 1309 > % pwd > /var/tmp > % grep libc d.out | head > % > > **** RUN usr.d and pwd after deleting libc in mod.d *** > % diff mod.d.old mod.d > 7c7 > < pid$1:libc::entry > --- > > pid$1:::entry > % > % kill -9 1309 > % usr.d & > [1] 1379 > % pwd > /var/tmp > % grep libc d.out | head > libc.so.1 _cleanup 1 > libc.so.1 _exithandle 1 > libc.so.1 _fflush_l_iops 1 > libc.so.1 _fflush_u 1 > libc.so.1 _getfp 1 > libc.so.1 _syscall6 1 > libc.so.1 _write 1 > libc.so.1 exit 1 > libc.so.1 fflush 1 > libc.so.1 getcwd 1 > % > > *********************** OS ****************************** > % cat /etc/release > Solaris Nevada snv_51a SPARC > Copyright 2006 Sun Microsystems, Inc. All Rights Reserved. > Use is subject to license terms. > Assembled 27 October 2006 > % uname -a > SunOS ctech104 5.11 snv_51 sun4u sparc SUNW,Serverblade1 > % > > > -- > ************************************************ > * C P Lin, Common Technology Project Lead. * > * Sun Microsystems Inc. * > * E-Mail: c.lin at sun.com * > * Address: 4150 Network Circle, M/S UMPK12-330 * > * Santa Clara, CA 95054 * > * Phone: 650/352-4967 Fax: 650/786-7816 * > ************************************************ > _______________________________________________ > dtrace-discuss mailing list > dtrace-discuss at opensolaris.org-- Adam Leventhal, Solaris Kernel Development http://blogs.sun.com/ahl
CHIAN-PHON LIN
2006-Nov-07 18:46 UTC
[dtrace-discuss] Fail to trace specific module in pid provider in snv_51a
Adam, Adam Leventhal wrote On 11/07/06 08:18,:> The actual name of the probe is ''pid123:libc.so.1:malloc:entry'' (for example), > rather than ''pid123:libc:malloc:entry''. We automatically change ''libc'' to > ''libc.so.1'' if the library exists, but if you use the -Z flag and there''s > nothing that matches the library name, we can''t make that change -- we don''t > know, for eaxmple, if ''libc'' is a stand-alone module that''s going to be > loaded or if it''s going to be ''libc.so.2'' or whatever.In fact, I already tried libc.so.1 and it didn''t work. I also tried libc* and it didn''t work either. The key problem here is that this behaviour is different from the one in the previous OS. We are building a function boundary coverage tool and rely on the existing Dtrace behaviour. If the behavious changes then our tool may not be stable from OS release to next release. I suspect that stop() and starting of mod.d at _start stage of the traced process contribute to libc not being picked up by Dtrace but this does not explain why libc got picked up when using ''pid123:::entry''. Thanks.> You can solve your problem by specifying the full library name. > > Adam > > On Mon, Nov 06, 2006 at 02:10:15PM -0800, CHIAN-PHON LIN wrote: > >>Hi, >> >>Dtrace in Solaris Nevada snv_51a was not able to >>trace specific module such as libc if I run usr.d and >>subsequent cmd.d and mod.d through stop() and prun >>sequence etc.. However, if I change "pid$1:libc::entry" >>to "pid$1:::entry" in mod.d, then libc can be traced. >>This behaviour is different from previous OS. >>In previous OS, libc can be traced with "pid$1:libc::entry". >>In this example, I simply tried to trace libc >>when "pwd" is executed. Below are 3 D-programs and >>procedures to reproduce this problem. >> >>*********************** usr.d ************************* >>#!/usr/sbin/dtrace -s >>#pragma D option quiet >>#pragma D option destructive >>proc:genunix:exec_common:exec-success >>/execname == "pwd"/ >>{ >> stop(); >> system("./cmd.d %d &", pid); >>} >>*********************** cmd.d ************************* >>#!/usr/sbin/dtrace -Zqs >>#pragma D option destructive >>BEGIN >>{ >> system("prun %d", $1); >>} >>pid$1::_start:entry >>/!progenyof($pid)/ >>{ >> stop(); >> system("./mod.d %d > d.out &", $1); >>} >>fbt:genunix:proc_exit:entry >>/pid == $1/ >>{ >> exit(0); >>} >>*********************** mod.d ************************* >>#!/usr/sbin/dtrace -Zqs >>#pragma D option destructive >>BEGIN >>{ >> system("prun %d", $1); >>} >>pid$1:libc::entry >>{ >> @funcs[probemod, probefunc] = count(); >>} >>fbt:genunix:proc_exit:entry >>/pid == $1/ >>{ >> exit(0); >>} >>END >>{ >> printa(@funcs); >>} >> >>***************** RUN usr.d and pwd ******************* >>% usr.d & >>[1] 1309 >>% pwd >>/var/tmp >>% grep libc d.out | head >>% >> >>**** RUN usr.d and pwd after deleting libc in mod.d *** >>% diff mod.d.old mod.d >>7c7 >>< pid$1:libc::entry >>--- >> >>>pid$1:::entry >> >>% >>% kill -9 1309 >>% usr.d & >>[1] 1379 >>% pwd >>/var/tmp >>% grep libc d.out | head >> libc.so.1 _cleanup 1 >> libc.so.1 _exithandle 1 >> libc.so.1 _fflush_l_iops 1 >> libc.so.1 _fflush_u 1 >> libc.so.1 _getfp 1 >> libc.so.1 _syscall6 1 >> libc.so.1 _write 1 >> libc.so.1 exit 1 >> libc.so.1 fflush 1 >> libc.so.1 getcwd 1 >>% >> >>*********************** OS ****************************** >>% cat /etc/release >> Solaris Nevada snv_51a SPARC >> Copyright 2006 Sun Microsystems, Inc. All Rights Reserved. >> Use is subject to license terms. >> Assembled 27 October 2006 >>% uname -a >>SunOS ctech104 5.11 snv_51 sun4u sparc SUNW,Serverblade1 >>% >> >> >>-- >>************************************************ >>* C P Lin, Common Technology Project Lead. * >>* Sun Microsystems Inc. * >>* E-Mail: c.lin at sun.com * >>* Address: 4150 Network Circle, M/S UMPK12-330 * >>* Santa Clara, CA 95054 * >>* Phone: 650/352-4967 Fax: 650/786-7816 * >>************************************************ >>_______________________________________________ >>dtrace-discuss mailing list >>dtrace-discuss at opensolaris.org > >-- ************************************************ * C P Lin, Common Technology Project Lead. * * Sun Microsystems Inc. * * E-Mail: c.lin at sun.com * * Address: 4150 Network Circle, M/S UMPK12-330 * * Santa Clara, CA 95054 * * Phone: 650/352-4967 Fax: 650/786-7816 * ************************************************
Adam Leventhal
2006-Nov-13 23:07 UTC
[dtrace-discuss] Fail to trace specific module in pid provider in snv_51a
There shouldn''t be any change in behavior between releases in this regard. I''m not sure how this could have happened -- can you confirm that you''re seeing this on the latest bits and try to reduce this to its simplest case? Thanks. Adam On Tue, Nov 07, 2006 at 10:46:40AM -0800, CHIAN-PHON LIN wrote:> Adam, > > Adam Leventhal wrote On 11/07/06 08:18,: > >The actual name of the probe is ''pid123:libc.so.1:malloc:entry'' (for > >example), > >rather than ''pid123:libc:malloc:entry''. We automatically change ''libc'' to > >''libc.so.1'' if the library exists, but if you use the -Z flag and there''s > >nothing that matches the library name, we can''t make that change -- we > >don''t > >know, for eaxmple, if ''libc'' is a stand-alone module that''s going to be > >loaded or if it''s going to be ''libc.so.2'' or whatever. > > In fact, I already tried libc.so.1 and it didn''t work. > I also tried libc* and it didn''t work either. The key > problem here is that this behaviour is different from the > one in the previous OS. We are building a function > boundary coverage tool and rely on the existing > Dtrace behaviour. If the behavious changes then our > tool may not be stable from OS release to next > release. I suspect that stop() and starting of mod.d > at _start stage of the traced process contribute to > libc not being picked up by Dtrace but this does not > explain why libc got picked up when using ''pid123:::entry''. > > Thanks. > > >You can solve your problem by specifying the full library name. > > > >Adam > > > >On Mon, Nov 06, 2006 at 02:10:15PM -0800, CHIAN-PHON LIN wrote: > > > >>Hi, > >> > >>Dtrace in Solaris Nevada snv_51a was not able to > >>trace specific module such as libc if I run usr.d and > >>subsequent cmd.d and mod.d through stop() and prun > >>sequence etc.. However, if I change "pid$1:libc::entry" > >>to "pid$1:::entry" in mod.d, then libc can be traced. > >>This behaviour is different from previous OS. > >>In previous OS, libc can be traced with "pid$1:libc::entry". > >>In this example, I simply tried to trace libc > >>when "pwd" is executed. Below are 3 D-programs and > >>procedures to reproduce this problem. > >> > >>*********************** usr.d ************************* > >>#!/usr/sbin/dtrace -s > >>#pragma D option quiet > >>#pragma D option destructive > >>proc:genunix:exec_common:exec-success > >>/execname == "pwd"/ > >>{ > >> stop(); > >> system("./cmd.d %d &", pid); > >>} > >>*********************** cmd.d ************************* > >>#!/usr/sbin/dtrace -Zqs > >>#pragma D option destructive > >>BEGIN > >>{ > >> system("prun %d", $1); > >>} > >>pid$1::_start:entry > >>/!progenyof($pid)/ > >>{ > >> stop(); > >> system("./mod.d %d > d.out &", $1); > >>} > >>fbt:genunix:proc_exit:entry > >>/pid == $1/ > >>{ > >> exit(0); > >>} > >>*********************** mod.d ************************* > >>#!/usr/sbin/dtrace -Zqs > >>#pragma D option destructive > >>BEGIN > >>{ > >> system("prun %d", $1); > >>} > >>pid$1:libc::entry > >>{ > >> @funcs[probemod, probefunc] = count(); > >>} > >>fbt:genunix:proc_exit:entry > >>/pid == $1/ > >>{ > >> exit(0); > >>} > >>END > >>{ > >> printa(@funcs); > >>} > >> > >>***************** RUN usr.d and pwd ******************* > >>% usr.d & > >>[1] 1309 > >>% pwd > >>/var/tmp > >>% grep libc d.out | head > >>% > >> > >>**** RUN usr.d and pwd after deleting libc in mod.d *** > >>% diff mod.d.old mod.d > >>7c7 > >>< pid$1:libc::entry > >>--- > >> > >>>pid$1:::entry > >> > >>% > >>% kill -9 1309 > >>% usr.d & > >>[1] 1379 > >>% pwd > >>/var/tmp > >>% grep libc d.out | head > >> libc.so.1 _cleanup 1 > >> libc.so.1 _exithandle 1 > >> libc.so.1 _fflush_l_iops 1 > >> libc.so.1 _fflush_u 1 > >> libc.so.1 _getfp 1 > >> libc.so.1 _syscall6 1 > >> libc.so.1 _write 1 > >> libc.so.1 exit 1 > >> libc.so.1 fflush 1 > >> libc.so.1 getcwd 1 > >>% > >> > >>*********************** OS ****************************** > >>% cat /etc/release > >> Solaris Nevada snv_51a SPARC > >> Copyright 2006 Sun Microsystems, Inc. All Rights Reserved. > >> Use is subject to license terms. > >> Assembled 27 October 2006 > >>% uname -a > >>SunOS ctech104 5.11 snv_51 sun4u sparc SUNW,Serverblade1 > >>% > >> > >> > >>-- > >>************************************************ > >>* C P Lin, Common Technology Project Lead. * > >>* Sun Microsystems Inc. * > >>* E-Mail: c.lin at sun.com * > >>* Address: 4150 Network Circle, M/S UMPK12-330 * > >>* Santa Clara, CA 95054 * > >>* Phone: 650/352-4967 Fax: 650/786-7816 * > >>************************************************ > >>_______________________________________________ > >>dtrace-discuss mailing list > >>dtrace-discuss at opensolaris.org > > > > > > -- > ************************************************ > * C P Lin, Common Technology Project Lead. * > * Sun Microsystems Inc. * > * E-Mail: c.lin at sun.com * > * Address: 4150 Network Circle, M/S UMPK12-330 * > * Santa Clara, CA 95054 * > * Phone: 650/352-4967 Fax: 650/786-7816 * > ************************************************-- Adam Leventhal, Solaris Kernel Development http://blogs.sun.com/ahl
CHIAN-PHON LIN
2006-Nov-14 00:05 UTC
[dtrace-discuss] Fail to trace specific module in pid provider in snv_51a
Adam, Adam Leventhal wrote On 11/13/06 15:07,:> There shouldn''t be any change in behavior between releases in this regard. > I''m not sure how this could have happened -- can you confirm that you''re > seeing this on the latest bits and try to reduce this to its simplest case?Yes. I did my best to reduce this to its simplest case and ran them on snv_48 and snv-51. The result were different. Thanks.> Thanks. > > Adam > > On Tue, Nov 07, 2006 at 10:46:40AM -0800, CHIAN-PHON LIN wrote: > >>Adam, >> >>Adam Leventhal wrote On 11/07/06 08:18,: >> >>>The actual name of the probe is ''pid123:libc.so.1:malloc:entry'' (for >>>example), >>>rather than ''pid123:libc:malloc:entry''. We automatically change ''libc'' to >>>''libc.so.1'' if the library exists, but if you use the -Z flag and there''s >>>nothing that matches the library name, we can''t make that change -- we >>>don''t >>>know, for eaxmple, if ''libc'' is a stand-alone module that''s going to be >>>loaded or if it''s going to be ''libc.so.2'' or whatever. >> >>In fact, I already tried libc.so.1 and it didn''t work. >>I also tried libc* and it didn''t work either. The key >>problem here is that this behaviour is different from the >>one in the previous OS. We are building a function >>boundary coverage tool and rely on the existing >>Dtrace behaviour. If the behavious changes then our >>tool may not be stable from OS release to next >>release. I suspect that stop() and starting of mod.d >>at _start stage of the traced process contribute to >>libc not being picked up by Dtrace but this does not >>explain why libc got picked up when using ''pid123:::entry''. >> >>Thanks. >> >> >>>You can solve your problem by specifying the full library name. >>> >>>Adam >>> >>>On Mon, Nov 06, 2006 at 02:10:15PM -0800, CHIAN-PHON LIN wrote: >>> >>> >>>>Hi, >>>> >>>>Dtrace in Solaris Nevada snv_51a was not able to >>>>trace specific module such as libc if I run usr.d and >>>>subsequent cmd.d and mod.d through stop() and prun >>>>sequence etc.. However, if I change "pid$1:libc::entry" >>>>to "pid$1:::entry" in mod.d, then libc can be traced. >>>>This behaviour is different from previous OS. >>>>In previous OS, libc can be traced with "pid$1:libc::entry". >>>>In this example, I simply tried to trace libc >>>>when "pwd" is executed. Below are 3 D-programs and >>>>procedures to reproduce this problem. >>>> >>>>*********************** usr.d ************************* >>>>#!/usr/sbin/dtrace -s >>>>#pragma D option quiet >>>>#pragma D option destructive >>>>proc:genunix:exec_common:exec-success >>>>/execname == "pwd"/ >>>>{ >>>>stop(); >>>>system("./cmd.d %d &", pid); >>>>} >>>>*********************** cmd.d ************************* >>>>#!/usr/sbin/dtrace -Zqs >>>>#pragma D option destructive >>>>BEGIN >>>>{ >>>>system("prun %d", $1); >>>>} >>>>pid$1::_start:entry >>>>/!progenyof($pid)/ >>>>{ >>>>stop(); >>>>system("./mod.d %d > d.out &", $1); >>>>} >>>>fbt:genunix:proc_exit:entry >>>>/pid == $1/ >>>>{ >>>>exit(0); >>>>} >>>>*********************** mod.d ************************* >>>>#!/usr/sbin/dtrace -Zqs >>>>#pragma D option destructive >>>>BEGIN >>>>{ >>>>system("prun %d", $1); >>>>} >>>>pid$1:libc::entry >>>>{ >>>>@funcs[probemod, probefunc] = count(); >>>>} >>>>fbt:genunix:proc_exit:entry >>>>/pid == $1/ >>>>{ >>>>exit(0); >>>>} >>>>END >>>>{ >>>>printa(@funcs); >>>>} >>>> >>>>***************** RUN usr.d and pwd ******************* >>>>% usr.d & >>>>[1] 1309 >>>>% pwd >>>>/var/tmp >>>>% grep libc d.out | head >>>>% >>>> >>>>**** RUN usr.d and pwd after deleting libc in mod.d *** >>>>% diff mod.d.old mod.d >>>>7c7 >>>>< pid$1:libc::entry >>>>--- >>>> >>>> >>>>>pid$1:::entry >>>> >>>>% >>>>% kill -9 1309 >>>>% usr.d & >>>>[1] 1379 >>>>% pwd >>>>/var/tmp >>>>% grep libc d.out | head >>>>libc.so.1 _cleanup 1 >>>>libc.so.1 _exithandle 1 >>>>libc.so.1 _fflush_l_iops 1 >>>>libc.so.1 _fflush_u 1 >>>>libc.so.1 _getfp 1 >>>>libc.so.1 _syscall6 1 >>>>libc.so.1 _write 1 >>>>libc.so.1 exit 1 >>>>libc.so.1 fflush 1 >>>>libc.so.1 getcwd 1 >>>>% >>>> >>>>*********************** OS ****************************** >>>>% cat /etc/release >>>> Solaris Nevada snv_51a SPARC >>>> Copyright 2006 Sun Microsystems, Inc. All Rights Reserved. >>>> Use is subject to license terms. >>>> Assembled 27 October 2006 >>>>% uname -a >>>>SunOS ctech104 5.11 snv_51 sun4u sparc SUNW,Serverblade1 >>>>% >>>> >>>> >>>>-- >>>>************************************************ >>>>* C P Lin, Common Technology Project Lead. * >>>>* Sun Microsystems Inc. * >>>>* E-Mail: c.lin at sun.com * >>>>* Address: 4150 Network Circle, M/S UMPK12-330 * >>>>* Santa Clara, CA 95054 * >>>>* Phone: 650/352-4967 Fax: 650/786-7816 * >>>>************************************************ >>>>_______________________________________________ >>>>dtrace-discuss mailing list >>>>dtrace-discuss at opensolaris.org >>> >>> >>-- >>************************************************ >>* C P Lin, Common Technology Project Lead. * >>* Sun Microsystems Inc. * >>* E-Mail: c.lin at sun.com * >>* Address: 4150 Network Circle, M/S UMPK12-330 * >>* Santa Clara, CA 95054 * >>* Phone: 650/352-4967 Fax: 650/786-7816 * >>************************************************ > >-- ************************************************ * C P Lin, Common Technology Project Lead. * * Sun Microsystems Inc. * * E-Mail: c.lin at sun.com * * Address: 4150 Network Circle, M/S UMPK12-330 * * Santa Clara, CA 95054 * * Phone: 650/352-4967 Fax: 650/786-7816 * ************************************************
Adam Leventhal
2006-Nov-14 06:57 UTC
[dtrace-discuss] Fail to trace specific module in pid provider in snv_51a
Jon Haslam was able to track this back to a problem in libproc introduced by BrandZ. There will be a fix soon. Adam On Mon, Nov 13, 2006 at 04:05:35PM -0800, CHIAN-PHON LIN wrote:> Adam, > > Adam Leventhal wrote On 11/13/06 15:07,: > >There shouldn''t be any change in behavior between releases in this regard. > >I''m not sure how this could have happened -- can you confirm that you''re > >seeing this on the latest bits and try to reduce this to its simplest case? > > Yes. I did my best to reduce this to its simplest case and ran them > on snv_48 and snv-51. The result were different. > > Thanks. > > >Thanks. > > > >Adam > > > >On Tue, Nov 07, 2006 at 10:46:40AM -0800, CHIAN-PHON LIN wrote: > > > >>Adam, > >> > >>Adam Leventhal wrote On 11/07/06 08:18,: > >> > >>>The actual name of the probe is ''pid123:libc.so.1:malloc:entry'' (for > >>>example), > >>>rather than ''pid123:libc:malloc:entry''. We automatically change ''libc'' to > >>>''libc.so.1'' if the library exists, but if you use the -Z flag and there''s > >>>nothing that matches the library name, we can''t make that change -- we > >>>don''t > >>>know, for eaxmple, if ''libc'' is a stand-alone module that''s going to be > >>>loaded or if it''s going to be ''libc.so.2'' or whatever. > >> > >>In fact, I already tried libc.so.1 and it didn''t work. > >>I also tried libc* and it didn''t work either. The key > >>problem here is that this behaviour is different from the > >>one in the previous OS. We are building a function > >>boundary coverage tool and rely on the existing > >>Dtrace behaviour. If the behavious changes then our > >>tool may not be stable from OS release to next > >>release. I suspect that stop() and starting of mod.d > >>at _start stage of the traced process contribute to > >>libc not being picked up by Dtrace but this does not > >>explain why libc got picked up when using ''pid123:::entry''. > >> > >>Thanks. > >> > >> > >>>You can solve your problem by specifying the full library name. > >>> > >>>Adam > >>> > >>>On Mon, Nov 06, 2006 at 02:10:15PM -0800, CHIAN-PHON LIN wrote: > >>> > >>> > >>>>Hi, > >>>> > >>>>Dtrace in Solaris Nevada snv_51a was not able to > >>>>trace specific module such as libc if I run usr.d and > >>>>subsequent cmd.d and mod.d through stop() and prun > >>>>sequence etc.. However, if I change "pid$1:libc::entry" > >>>>to "pid$1:::entry" in mod.d, then libc can be traced. > >>>>This behaviour is different from previous OS. > >>>>In previous OS, libc can be traced with "pid$1:libc::entry". > >>>>In this example, I simply tried to trace libc > >>>>when "pwd" is executed. Below are 3 D-programs and > >>>>procedures to reproduce this problem. > >>>> > >>>>*********************** usr.d ************************* > >>>>#!/usr/sbin/dtrace -s > >>>>#pragma D option quiet > >>>>#pragma D option destructive > >>>>proc:genunix:exec_common:exec-success > >>>>/execname == "pwd"/ > >>>>{ > >>>>stop(); > >>>>system("./cmd.d %d &", pid); > >>>>} > >>>>*********************** cmd.d ************************* > >>>>#!/usr/sbin/dtrace -Zqs > >>>>#pragma D option destructive > >>>>BEGIN > >>>>{ > >>>>system("prun %d", $1); > >>>>} > >>>>pid$1::_start:entry > >>>>/!progenyof($pid)/ > >>>>{ > >>>>stop(); > >>>>system("./mod.d %d > d.out &", $1); > >>>>} > >>>>fbt:genunix:proc_exit:entry > >>>>/pid == $1/ > >>>>{ > >>>>exit(0); > >>>>} > >>>>*********************** mod.d ************************* > >>>>#!/usr/sbin/dtrace -Zqs > >>>>#pragma D option destructive > >>>>BEGIN > >>>>{ > >>>>system("prun %d", $1); > >>>>} > >>>>pid$1:libc::entry > >>>>{ > >>>>@funcs[probemod, probefunc] = count(); > >>>>} > >>>>fbt:genunix:proc_exit:entry > >>>>/pid == $1/ > >>>>{ > >>>>exit(0); > >>>>} > >>>>END > >>>>{ > >>>>printa(@funcs); > >>>>} > >>>> > >>>>***************** RUN usr.d and pwd ******************* > >>>>% usr.d & > >>>>[1] 1309 > >>>>% pwd > >>>>/var/tmp > >>>>% grep libc d.out | head > >>>>% > >>>> > >>>>**** RUN usr.d and pwd after deleting libc in mod.d *** > >>>>% diff mod.d.old mod.d > >>>>7c7 > >>>>< pid$1:libc::entry > >>>>--- > >>>> > >>>> > >>>>>pid$1:::entry > >>>> > >>>>% > >>>>% kill -9 1309 > >>>>% usr.d & > >>>>[1] 1379 > >>>>% pwd > >>>>/var/tmp > >>>>% grep libc d.out | head > >>>>libc.so.1 _cleanup 1 > >>>>libc.so.1 _exithandle 1 > >>>>libc.so.1 _fflush_l_iops 1 > >>>>libc.so.1 _fflush_u 1 > >>>>libc.so.1 _getfp 1 > >>>>libc.so.1 _syscall6 1 > >>>>libc.so.1 _write 1 > >>>>libc.so.1 exit 1 > >>>>libc.so.1 fflush 1 > >>>>libc.so.1 getcwd 1 > >>>>% > >>>> > >>>>*********************** OS ****************************** > >>>>% cat /etc/release > >>>> Solaris Nevada snv_51a SPARC > >>>> Copyright 2006 Sun Microsystems, Inc. All Rights Reserved. > >>>> Use is subject to license terms. > >>>> Assembled 27 October 2006 > >>>>% uname -a > >>>>SunOS ctech104 5.11 snv_51 sun4u sparc SUNW,Serverblade1 > >>>>% > >>>> > >>>> > >>>>-- > >>>>************************************************ > >>>>* C P Lin, Common Technology Project Lead. * > >>>>* Sun Microsystems Inc. * > >>>>* E-Mail: c.lin at sun.com * > >>>>* Address: 4150 Network Circle, M/S UMPK12-330 * > >>>>* Santa Clara, CA 95054 * > >>>>* Phone: 650/352-4967 Fax: 650/786-7816 * > >>>>************************************************ > >>>>_______________________________________________ > >>>>dtrace-discuss mailing list > >>>>dtrace-discuss at opensolaris.org > >>> > >>> > >>-- > >>************************************************ > >>* C P Lin, Common Technology Project Lead. * > >>* Sun Microsystems Inc. * > >>* E-Mail: c.lin at sun.com * > >>* Address: 4150 Network Circle, M/S UMPK12-330 * > >>* Santa Clara, CA 95054 * > >>* Phone: 650/352-4967 Fax: 650/786-7816 * > >>************************************************ > > > > > > -- > ************************************************ > * C P Lin, Common Technology Project Lead. * > * Sun Microsystems Inc. * > * E-Mail: c.lin at sun.com * > * Address: 4150 Network Circle, M/S UMPK12-330 * > * Santa Clara, CA 95054 * > * Phone: 650/352-4967 Fax: 650/786-7816 * > ************************************************-- Adam Leventhal, Solaris Kernel Development http://blogs.sun.com/ahl
Jon Haslam
2006-Nov-14 09:04 UTC
[dtrace-discuss] Fail to trace specific module in pid provider in snv_51a
>Jon Haslam was able to track this back to a problem in libproc introduced by >BrandZ. There will be a fix soon. > >For the interested parties this is: 6493158: pid provider having problems matching module names Jon.>Adam > >On Mon, Nov 13, 2006 at 04:05:35PM -0800, CHIAN-PHON LIN wrote: > > >>Adam, >> >>Adam Leventhal wrote On 11/13/06 15:07,: >> >> >>>There shouldn''t be any change in behavior between releases in this regard. >>>I''m not sure how this could have happened -- can you confirm that you''re >>>seeing this on the latest bits and try to reduce this to its simplest case? >>> >>> >>Yes. I did my best to reduce this to its simplest case and ran them >>on snv_48 and snv-51. The result were different. >> >>Thanks. >> >> >> >>>Thanks. >>> >>>Adam >>> >>>On Tue, Nov 07, 2006 at 10:46:40AM -0800, CHIAN-PHON LIN wrote: >>> >>> >>> >>>>Adam, >>>> >>>>Adam Leventhal wrote On 11/07/06 08:18,: >>>> >>>> >>>> >>>>>The actual name of the probe is ''pid123:libc.so.1:malloc:entry'' (for >>>>>example), >>>>>rather than ''pid123:libc:malloc:entry''. We automatically change ''libc'' to >>>>>''libc.so.1'' if the library exists, but if you use the -Z flag and there''s >>>>>nothing that matches the library name, we can''t make that change -- we >>>>>don''t >>>>>know, for eaxmple, if ''libc'' is a stand-alone module that''s going to be >>>>>loaded or if it''s going to be ''libc.so.2'' or whatever. >>>>> >>>>> >>>>In fact, I already tried libc.so.1 and it didn''t work. >>>>I also tried libc* and it didn''t work either. The key >>>>problem here is that this behaviour is different from the >>>>one in the previous OS. We are building a function >>>>boundary coverage tool and rely on the existing >>>>Dtrace behaviour. If the behavious changes then our >>>>tool may not be stable from OS release to next >>>>release. I suspect that stop() and starting of mod.d >>>>at _start stage of the traced process contribute to >>>>libc not being picked up by Dtrace but this does not >>>>explain why libc got picked up when using ''pid123:::entry''. >>>> >>>>Thanks. >>>> >>>> >>>> >>>> >>>>>You can solve your problem by specifying the full library name. >>>>> >>>>>Adam >>>>> >>>>>On Mon, Nov 06, 2006 at 02:10:15PM -0800, CHIAN-PHON LIN wrote: >>>>> >>>>> >>>>> >>>>> >>>>>>Hi, >>>>>> >>>>>>Dtrace in Solaris Nevada snv_51a was not able to >>>>>>trace specific module such as libc if I run usr.d and >>>>>>subsequent cmd.d and mod.d through stop() and prun >>>>>>sequence etc.. However, if I change "pid$1:libc::entry" >>>>>>to "pid$1:::entry" in mod.d, then libc can be traced. >>>>>>This behaviour is different from previous OS. >>>>>>In previous OS, libc can be traced with "pid$1:libc::entry". >>>>>>In this example, I simply tried to trace libc >>>>>>when "pwd" is executed. Below are 3 D-programs and >>>>>>procedures to reproduce this problem. >>>>>> >>>>>>*********************** usr.d ************************* >>>>>>#!/usr/sbin/dtrace -s >>>>>>#pragma D option quiet >>>>>>#pragma D option destructive >>>>>>proc:genunix:exec_common:exec-success >>>>>>/execname == "pwd"/ >>>>>>{ >>>>>>stop(); >>>>>>system("./cmd.d %d &", pid); >>>>>>} >>>>>>*********************** cmd.d ************************* >>>>>>#!/usr/sbin/dtrace -Zqs >>>>>>#pragma D option destructive >>>>>>BEGIN >>>>>>{ >>>>>>system("prun %d", $1); >>>>>>} >>>>>>pid$1::_start:entry >>>>>>/!progenyof($pid)/ >>>>>>{ >>>>>>stop(); >>>>>>system("./mod.d %d > d.out &", $1); >>>>>>} >>>>>>fbt:genunix:proc_exit:entry >>>>>>/pid == $1/ >>>>>>{ >>>>>>exit(0); >>>>>>} >>>>>>*********************** mod.d ************************* >>>>>>#!/usr/sbin/dtrace -Zqs >>>>>>#pragma D option destructive >>>>>>BEGIN >>>>>>{ >>>>>>system("prun %d", $1); >>>>>>} >>>>>>pid$1:libc::entry >>>>>>{ >>>>>>@funcs[probemod, probefunc] = count(); >>>>>>} >>>>>>fbt:genunix:proc_exit:entry >>>>>>/pid == $1/ >>>>>>{ >>>>>>exit(0); >>>>>>} >>>>>>END >>>>>>{ >>>>>>printa(@funcs); >>>>>>} >>>>>> >>>>>>***************** RUN usr.d and pwd ******************* >>>>>>% usr.d & >>>>>>[1] 1309 >>>>>>% pwd >>>>>>/var/tmp >>>>>>% grep libc d.out | head >>>>>>% >>>>>> >>>>>>**** RUN usr.d and pwd after deleting libc in mod.d *** >>>>>>% diff mod.d.old mod.d >>>>>>7c7 >>>>>>< pid$1:libc::entry >>>>>>--- >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>>pid$1:::entry >>>>>>> >>>>>>> >>>>>>% >>>>>>% kill -9 1309 >>>>>>% usr.d & >>>>>>[1] 1379 >>>>>>% pwd >>>>>>/var/tmp >>>>>>% grep libc d.out | head >>>>>>libc.so.1 _cleanup 1 >>>>>>libc.so.1 _exithandle 1 >>>>>>libc.so.1 _fflush_l_iops 1 >>>>>>libc.so.1 _fflush_u 1 >>>>>>libc.so.1 _getfp 1 >>>>>>libc.so.1 _syscall6 1 >>>>>>libc.so.1 _write 1 >>>>>>libc.so.1 exit 1 >>>>>>libc.so.1 fflush 1 >>>>>>libc.so.1 getcwd 1 >>>>>>% >>>>>> >>>>>>*********************** OS ****************************** >>>>>>% cat /etc/release >>>>>> Solaris Nevada snv_51a SPARC >>>>>> Copyright 2006 Sun Microsystems, Inc. All Rights Reserved. >>>>>> Use is subject to license terms. >>>>>> Assembled 27 October 2006 >>>>>>% uname -a >>>>>>SunOS ctech104 5.11 snv_51 sun4u sparc SUNW,Serverblade1 >>>>>>% >>>>>> >>>>>> >>>>>>-- >>>>>>************************************************ >>>>>>* C P Lin, Common Technology Project Lead. * >>>>>>* Sun Microsystems Inc. * >>>>>>* E-Mail: c.lin at sun.com * >>>>>>* Address: 4150 Network Circle, M/S UMPK12-330 * >>>>>>* Santa Clara, CA 95054 * >>>>>>* Phone: 650/352-4967 Fax: 650/786-7816 * >>>>>>************************************************ >>>>>>_______________________________________________ >>>>>>dtrace-discuss mailing list >>>>>>dtrace-discuss at opensolaris.org >>>>>> >>>>>> >>>>> >>>>> >>>>-- >>>>************************************************ >>>>* C P Lin, Common Technology Project Lead. * >>>>* Sun Microsystems Inc. * >>>>* E-Mail: c.lin at sun.com * >>>>* Address: 4150 Network Circle, M/S UMPK12-330 * >>>>* Santa Clara, CA 95054 * >>>>* Phone: 650/352-4967 Fax: 650/786-7816 * >>>>************************************************ >>>> >>>> >>> >>> >>-- >>************************************************ >>* C P Lin, Common Technology Project Lead. * >>* Sun Microsystems Inc. * >>* E-Mail: c.lin at sun.com * >>* Address: 4150 Network Circle, M/S UMPK12-330 * >>* Santa Clara, CA 95054 * >>* Phone: 650/352-4967 Fax: 650/786-7816 * >>************************************************ >> >> > > >