Folks - we''ve put together a patch to add a general dynamic tracing infrastructure to the mozilla build system to make it easy to add new dtrace probes to the Mozilla codebase. The proposal, patch and sample scripts are all up on bugzilla. https://bugzilla.mozilla.org/show_bug.cgi?id=370906 Hopefully if we can get this accepted we''ll be able to add lots of other interesting probes, including Brendan Greg''s Javascript ones. For now we''ve just added a few to the new layout engine as a proof of concept to help track timings on layout phases, namely paint, reflow and frame construction. Cheers, JR, Padraig and Alfred.
Hey John, Your proposal looks good. Having to wrap each probe in an #ifdef is a bit annoying. Would a program that generates the stubbed out provider header file help make this easier? It seems like a simple version of ''dtrace -h'' would make this and other cross-platform applications much easier to maintain. Adam On Mon, Feb 19, 2007 at 05:07:38PM +0000, John Rice wrote:> Folks - we''ve put together a patch to add a general dynamic tracing > infrastructure to the mozilla build system to make it easy to add new > dtrace probes to the Mozilla codebase. > > The proposal, patch and sample scripts are all up on bugzilla. > > https://bugzilla.mozilla.org/show_bug.cgi?id=370906 > > Hopefully if we can get this accepted we''ll be able to add lots of other > interesting probes, including Brendan Greg''s Javascript ones. For now > we''ve just added a few to the new layout engine as a proof of concept to > help track timings on layout phases, namely paint, reflow and frame > construction. > > Cheers, > > JR, Padraig and Alfred. > _______________________________________________ > dtrace-discuss mailing list > dtrace-discuss at opensolaris.org-- Adam Leventhal, Solaris Kernel Development http://blogs.sun.com/ahl
Thanks Adam - what we need is a simplified dtrace -h which doesn''t depend on dtrace :) The mozilla folks have a build bot that periodically regenerates files like configure, timeless (Josh) asked me if we could do the same for the mozilla-trace.h header. The problem is this would need to happen on a linux build machine so using dtrace -h is out. We will have to have a script that processes the mozilla-trace.d probes file and generates the header for us. If we know the mozilla-trace.h file will always be there regardless of the architecture, then we can add in appropriate wrappers to avoid adding in the #ifdef in the code. Only thing we''d have to wrap would be the header include, will keep things a lot cleaner. JR P.s. The guys on the buglist where asking about probe effect, I answered them as best I could from the usenix article, but I''m no kernel hacker, you might want to check out the bug comments - cheers. https://bugzilla.mozilla.org/show_bug.cgi?id=370906 Adam Leventhal wrote:> Hey John, > > Your proposal looks good. Having to wrap each probe in an #ifdef is a bit > annoying. Would a program that generates the stubbed out provider header file > help make this easier? It seems like a simple version of ''dtrace -h'' would > make this and other cross-platform applications much easier to maintain. > > Adam > > On Mon, Feb 19, 2007 at 05:07:38PM +0000, John Rice wrote: > >> Folks - we''ve put together a patch to add a general dynamic tracing >> infrastructure to the mozilla build system to make it easy to add new >> dtrace probes to the Mozilla codebase. >> >> The proposal, patch and sample scripts are all up on bugzilla. >> >> https://bugzilla.mozilla.org/show_bug.cgi?id=370906 >> >> Hopefully if we can get this accepted we''ll be able to add lots of other >> interesting probes, including Brendan Greg''s Javascript ones. For now >> we''ve just added a few to the new layout engine as a proof of concept to >> help track timings on layout phases, namely paint, reflow and frame >> construction. >> >> Cheers, >> >> JR, Padraig and Alfred. >> _______________________________________________ >> dtrace-discuss mailing list >> dtrace-discuss at opensolaris.org >> > >
Discussing this with Padraig, we think this might not be the best way to go. Looking at the dtrace code it would seem to be a lot of work to pull this out, though if you want to do it no problems ;) We''ll see if the mozilla folks would be happy with us checking in the mozilla-trace.h into cvs. That way it''s always there and the build bot doesn''t need to generate it. If a developer is modifying the top level mozilla-trace.d probes file, then when they run a configure locally it will regenerate the mozilla-trace.h file for them, so they can test out the new probes. Naturally such a developer will need to be doing this on a machine with dtrace support or it makes little sense. When they are done testing their new probes all they have to do is check this into cvs (or generate a patch). Will keep you posted. JR John Rice wrote:> Thanks Adam - what we need is a simplified dtrace -h which doesn''t > depend on dtrace :) > > The mozilla folks have a build bot that periodically regenerates files > like configure, timeless (Josh) asked me if we could do the same for > the mozilla-trace.h header. The problem is this would need to happen > on a linux build machine so using dtrace -h is out. > > We will have to have a script that processes the mozilla-trace.d > probes file and generates the header for us. If we know the > mozilla-trace.h file will always be there regardless of the > architecture, then we can add in appropriate wrappers to avoid adding > in the #ifdef in the code. Only thing we''d have to wrap would be the > header include, will keep things a lot cleaner. > > JR > > P.s. The guys on the buglist where asking about probe effect, I > answered them as best I could from the usenix article, but I''m no > kernel hacker, you might want to check out the bug comments - cheers. > > https://bugzilla.mozilla.org/show_bug.cgi?id=370906 > > > > Adam Leventhal wrote: >> Hey John, >> >> Your proposal looks good. Having to wrap each probe in an #ifdef is a >> bit >> annoying. Would a program that generates the stubbed out provider >> header file >> help make this easier? It seems like a simple version of ''dtrace -h'' >> would >> make this and other cross-platform applications much easier to maintain. >> >> Adam >> >> On Mon, Feb 19, 2007 at 05:07:38PM +0000, John Rice wrote: >> >>> Folks - we''ve put together a patch to add a general dynamic tracing >>> infrastructure to the mozilla build system to make it easy to add >>> new dtrace probes to the Mozilla codebase. >>> >>> The proposal, patch and sample scripts are all up on bugzilla. >>> >>> https://bugzilla.mozilla.org/show_bug.cgi?id=370906 >>> >>> Hopefully if we can get this accepted we''ll be able to add lots of >>> other interesting probes, including Brendan Greg''s Javascript ones. >>> For now we''ve just added a few to the new layout engine as a proof >>> of concept to help track timings on layout phases, namely paint, >>> reflow and frame construction. >>> >>> Cheers, >>> >>> JR, Padraig and Alfred. >>> _______________________________________________ >>> dtrace-discuss mailing list >>> dtrace-discuss at opensolaris.org >>> >> >> > > _______________________________________________ > dtrace-discuss mailing list > dtrace-discuss at opensolaris.org
LGreenwood at exceededucation.com
2007-Mar-01 14:00 UTC
[dtrace-discuss] Dtrace script locking up workstation
Hi I have a student who made a typo in a script, he typed a "0" instead of a ")". When he ran the script it ran and locked up his workstation. Running on an unpatched Soloaris 10 01/06 (not my choice, it''s what Sun jump the machines for in this class). Is this expected behaviour? Known behaviour that is fixed? Part of the spiel about dtrace is pointing out that it''s written to beas non-intrusive as possible - so I''d like to be able to explain why it happened, and hopefully point out that it won''t happen to him in the real world. Thank you Cheers, Liam -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.opensolaris.org/pipermail/dtrace-discuss/attachments/20070301/24604bf6/attachment.html>
Michael Schuster
2007-Mar-01 14:03 UTC
[dtrace-discuss] Dtrace script locking up workstation
LGreenwood at exceededucation.com wrote:> > Hi > > I have a student who made a typo in a script, he typed a "0" instead of > a ")". When he ran the script it ran and locked up his workstation. > Running on an unpatched Soloaris 10 01/06 (not my choice, it''s what Sun > jump the machines for in this class). > > Is this expected behaviour? Known behaviour that is fixed? Part of the > spiel about dtrace is pointing out that it''s written to beas > non-intrusive as possible - so I''d like to be able to explain why it > happened, and hopefully point out that it won''t happen to him in the > real world.you need to provide more information - send us the script (or a pointer, if it''s too long), point out where the mistake was made, and some information on the machine in use. Michael -- Michael Schuster Sun Microsystems, Inc.
LGreenwood at exceededucation.com
2007-Mar-01 15:07 UTC
[dtrace-discuss] Dtrace script locking up workstation
Uni-processor SunBlade 1000, 1GB memory, 2x 36GB drives, Solaris 10 01/06
1 #!/usr/sbin/dtrace -qs
2
3 io:::start
4 / args[0]->b_flags&B_READ /
5 {
6 start[args[0]->b_edev, args[0]->b_blkno] = timestamp;
7 }
8
9 io:::done
10 /start[args[0]->b_edev, args[0]->b_blkno]/
11 {
12 elapsed = (timestamp - start[args[0]->b_edev,
args[0]->b_blkno])/1000000;
13 @["Read elapsed time:"] = lquantize(elapsed,0,50,1);
14 }
On Line 12 he typed "b_blkno]0/1000000;" instead of the
"b_blkno])/1000000;" as shown. He got no errors on running, but
iteffectively locked up his machine.
Cheers, Liam
Michael Schuster <Michael.Schuster at Sun.COM>
Sent by: Michael.Schuster at Sun.COM
03/01/07 09:03 AM
To: LGreenwood at exceededucation.com
cc: dtrace-discuss at opensolaris.org
Subject: Re: [dtrace-discuss] Dtrace script locking up
workstation
LGreenwood at exceededucation.com wrote:>
> Hi
>
> I have a student who made a typo in a script, he typed a "0"
instead of
> a ")". When he ran the script it ran and locked up his
workstation.
> Running on an unpatched Soloaris 10 01/06 (not my choice, it''s
what Sun
> jump the machines for in this class).
>
> Is this expected behaviour? Known behaviour that is fixed? Part of the
> spiel about dtrace is pointing out that it''s written to beas
> non-intrusive as possible - so I''d like to be able to explain why
it
> happened, and hopefully point out that it won''t happen to him in
the
> real world.
you need to provide more information - send us the script (or a pointer,
if
it''s too long), point out where the mistake was made, and some
information
on the machine in use.
Michael
--
Michael Schuster
Sun Microsystems, Inc.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://mail.opensolaris.org/pipermail/dtrace-discuss/attachments/20070301/bf929c85/attachment.html>
Michael Schuster
2007-Mar-01 15:19 UTC
[dtrace-discuss] Dtrace script locking up workstation
LGreenwood at exceededucation.com wrote:> > Uni-processor SunBlade 1000, 1GB memory, 2x 36GB drives, Solaris 10 01/06 > > 1 #!/usr/sbin/dtrace -qs > 2 > 3 io:::start > 4 / args[0]->b_flags&B_READ / > 5 { > 6 start[args[0]->b_edev, args[0]->b_blkno] = timestamp; > 7 } > 8 > 9 io:::done > 10 /start[args[0]->b_edev, args[0]->b_blkno]/ > 11 { > 12 elapsed = (timestamp - start[args[0]->b_edev, > args[0]->b_blkno])/1000000; > 13 @["Read elapsed time:"] = lquantize(elapsed,0,50,1); > 14 } > > On Line 12 he typed "b_blkno]0/1000000;" instead of the > "b_blkno])/1000000;" as shown. He got no errors on running, but > iteffectively locked up his machine.I just tested this on Nevada, build 56, and I get an error message: dtrace: failed to compile script ./iotest.d: line 12: syntax error near "0" which is exactly what I''d have expected. I''d be surprised if Solaris 10 behaved differently in that respect (although someone more familiar with the bugs fixed in DTrace should probably say so), so are you 100% sure that there wasn''t another typo anywhere else in the script? What else was your student doing to cause I/O being reported? Michael -- Michael Schuster Sun Microsystems, Inc.
LGreenwood at exceededucation.com writes:> Uni-processor SunBlade 1000, 1GB memory, 2x 36GB drives, Solaris 10 01/06[...]> On Line 12 he typed "b_blkno]0/1000000;" instead of the > "b_blkno])/1000000;" as shown. He got no errors on running, but > iteffectively locked up his machine.I just tried the same thing on a Solaris 10 01/06 (update 1) SPARC system, and I got: # ./foo.d dtrace: failed to compile script ./foo.d: line 12: syntax error near "0" # Granted, it was a T2000, and not an SB1000, but it seems likely to me that some other factor is involved here. -- James Carlson, Solaris Networking <james.d.carlson at sun.com> Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
LGreenwood at exceededucation.com
2007-Mar-01 16:09 UTC
[dtrace-discuss] Dtrace script locking up workstation
He says that he rebooted his box, then found the error mentioned (0
instead of )). He re-ran with out that fixed and dtrace gave him an error
on another typo. We can''t reproduce the hang now (of course). Thank
you
for the help. If I can get the hang reproduced I''ll send it send an
update. This is the 2nd class I''ve done where someone has managed to
had
their machine entering the scripts givine in the course (SA-225) - so I
might yet have a chance to find it.
Cheers, Liam
James Carlson <james.d.carlson at Sun.COM>
03/01/07 10:34 AM
To: LGreenwood at exceededucation.com
cc: Michael Schuster <Michael.Schuster at Sun.COM>,
dtrace-discuss at opensolaris.org
Subject: Re: [dtrace-discuss] Dtrace script locking up
workstation
LGreenwood at exceededucation.com writes:> Uni-processor SunBlade 1000, 1GB memory, 2x 36GB drives, Solaris 10
01/06
[...]> On Line 12 he typed "b_blkno]0/1000000;" instead of the
> "b_blkno])/1000000;" as shown. He got no errors on running, but
> iteffectively locked up his machine.
I just tried the same thing on a Solaris 10 01/06 (update 1) SPARC
system, and I got:
# ./foo.d
dtrace: failed to compile script ./foo.d: line 12: syntax error near
"0"
#
Granted, it was a T2000, and not an SB1000, but it seems likely to me
that some other factor is involved here.
--
James Carlson, Solaris Networking <james.d.carlson at
sun.com>
Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://mail.opensolaris.org/pipermail/dtrace-discuss/attachments/20070301/92d51e3a/attachment.html>
Michael Schuster
2007-Mar-01 16:19 UTC
[dtrace-discuss] Dtrace script locking up workstation
LGreenwood at exceededucation.com wrote:> > He says that he rebooted his box, then found the error mentioned (0 > instead of )). He re-ran with out that fixed and dtrace gave him an > error on another typo.*another* typo? what was that? or do you mean to say when he re-ran the test with the same typo he got an error message, like James and I reported? Michael -- Michael Schuster Sun Microsystems, Inc.