James McIlree
2008-Aug-13 22:03 UTC
[dtrace-discuss] The strange case of the missing/extra probe...
I have a user that was adding some rather expensive probes to library
code.
Their code ended up factoring in such a way that the main line code
had IS_ENABLED()
tests guarding calls to another function that did the real work of
argument construction
and calling the actual dtrace probe.
Somewhat unusually, when run, dtrace reports multiple probes instead
of just one.
I boiled the test case down into these two functions:
void functionA(int value) {
if (SIMPLE_MYSIMPLEPROBE_ENABLED()) {
printf("No probe called, but mySimpleProbe() is enabled\n");
}
}
void functionB(int value) {
if (SIMPLE_MYSIMPLEPROBE_ENABLED()) {
SIMPLE_MYSIMPLEPROBE(value);
}
}
On both Solaris and OS X, when an app containing these functions is
run, dtrace
reports:
/home/ovrskeek# dtrace -l -n "Simple*:::"
ID PROVIDER MODULE FUNCTION
NAME
512 Simple15950 simple functionB
mySimpleProbe
513 Simple15950 simple functionA
mySimpleProbe
It seems to me like we''re missing something here. If I have both an
is-enabled
and a regular probe in the same function, dtrace reports finding one
probe. If I have
either separately, dtrace reports finding one probe. Somehow, I''m
either losing a probe
in the "both" case, or gaining one in the IS_ENABLED() only case.
This is a bit confusing to consumers as well, consider the case of
/home/ovrskeek# dtrace -l -n "Simple*:::"
ID PROVIDER MODULE FUNCTION
NAME
512 Simple15950 simple functionB
mySimpleProbe
513 Simple15950 simple functionA
mySimpleProbe
/home/ovrskeek# dtrace -n "Simple*::functionA:"
dtrace: description ''Simple*::functionA:'' matched 1 probe
DTrace told me I had a probe in functionA, I *know* functionA is
being called, but
no output?
Of course, if we eliminate all IS_ENABLED probes, then they cannot be
used stand-alone.
Darned if we do, darned if we don''t :-).
I''m thinking perhaps we need a visual clue that a given probe is is-
enabled only?
Is there a better way to convey to consumers the type & number of
probes at a given point?
It seem like there are usage scenarios where you need information that
isn''t available (today)
without inspecting the source.
James M
Adam Leventhal
2008-Aug-21 01:35 UTC
[dtrace-discuss] The strange case of the missing/extra probe...
Hey James, This is all working as intended. As you know, a DTrace probe is identified by the four-tuple of provider, module, function, and name. Two locations for a USDT probe will differ only in the function components. This is true of is-enabled probes as well as normal probes. There are two things we could do to make the case you describe less confusing. One is to indicate that a given probe is exclusively an is-enabled site. That seems like a questionable practice, but I could imagine an implementation where that arrangement might be the most logical. The second thing we could do is have a mode for dtrace -l in which we only listed the components of the probe that were relevant. For example, it''s unusual for a user to enable only _some_ SDT or USDT probes so in this mode those would be coalesced into a single listing. What do you think? Adam On Wed, Aug 13, 2008 at 03:03:44PM -0700, James McIlree wrote:> > I have a user that was adding some rather expensive probes to library > code. > Their code ended up factoring in such a way that the main line code > had IS_ENABLED() > tests guarding calls to another function that did the real work of > argument construction > and calling the actual dtrace probe. > > Somewhat unusually, when run, dtrace reports multiple probes instead > of just one. > > I boiled the test case down into these two functions: > > void functionA(int value) { > if (SIMPLE_MYSIMPLEPROBE_ENABLED()) { > printf("No probe called, but mySimpleProbe() is enabled\n"); > } > } > > void functionB(int value) { > if (SIMPLE_MYSIMPLEPROBE_ENABLED()) { > SIMPLE_MYSIMPLEPROBE(value); > } > } > > On both Solaris and OS X, when an app containing these functions is > run, dtrace > reports: > > /home/ovrskeek# dtrace -l -n "Simple*:::" > ID PROVIDER MODULE FUNCTION > NAME > 512 Simple15950 simple functionB > mySimpleProbe > 513 Simple15950 simple functionA > mySimpleProbe > > It seems to me like we''re missing something here. If I have both an > is-enabled > and a regular probe in the same function, dtrace reports finding one > probe. If I have > either separately, dtrace reports finding one probe. Somehow, I''m > either losing a probe > in the "both" case, or gaining one in the IS_ENABLED() only case. > > This is a bit confusing to consumers as well, consider the case of > > /home/ovrskeek# dtrace -l -n "Simple*:::" > ID PROVIDER MODULE FUNCTION > NAME > 512 Simple15950 simple functionB > mySimpleProbe > 513 Simple15950 simple functionA > mySimpleProbe > /home/ovrskeek# dtrace -n "Simple*::functionA:" > dtrace: description ''Simple*::functionA:'' matched 1 probe > > DTrace told me I had a probe in functionA, I *know* functionA is > being called, but > no output? > > Of course, if we eliminate all IS_ENABLED probes, then they cannot be > used stand-alone. > > Darned if we do, darned if we don''t :-). > > I''m thinking perhaps we need a visual clue that a given probe is is- > enabled only? > > Is there a better way to convey to consumers the type & number of > probes at a given point? > It seem like there are usage scenarios where you need information that > isn''t available (today) > without inspecting the source. > > James M > > _______________________________________________ > dtrace-discuss mailing list > dtrace-discuss at opensolaris.org-- Adam Leventhal, Fishworks http://blogs.sun.com/ahl