dtrace discuss - Sep 2006 - Probe description does not match any probes

[Perhaps someone could rename this list to dtrace-matt-problems-discuss?]

If I run this script against my binary (which contains a USDT probe called
''concurrentq-latency''):

:::
/ probename == "concurrentq-latency" /
{
	printf("[%s]:[%s]:[%s]\n", probeprov, probefunc, probename);
}

I get this output:

dtrace: script ''testq.d'' matched 46056 probes
dtrace: pid 26257 has exited
CPU     ID                    FUNCTION:NAME
  2  46076 dequeue_thread:concurrentq-latency
[tests26257]:[dequeue_thread]:[concurrentq-latency]

However, if I try to specify the probe in the ''normal''
fashion:

:::concurrentq-latency
{
	printf("[%s]:[%s]:[%s]\n", probeprov, probefunc, probename);
}

I get this instead:

dtrace: failed to compile script testq.d: line 1: probe description
:::concurrentq-latency does not match any probes

How does dtrace determine the existence of probes within a given binary, and
what might cause it not to ''see'' probes which *do* in fact
exist...?

Thanks,

Matt.
 
 
This message posted from opensolaris.org

Hi Matt,

When you run a program with DTrace (I assume you''re using -c),
dtrace(1M)
runs the program, let''s the linker bring in all the libraries, and
looks
through the loaded binaries for any USDT probes. If the library containing
the probe in question is loaded at some time in the future (via dlopen(3C))
DTrace won''t find the probe and will report the error you saw.

You can ignore the error by using the ''-Z'' option:

        -Z  permit probe descriptions that match zero probes

When the probe you''re interested in is created (when the library is
loaded),
it will match your enabling.

Adam

On Thu, Sep 21, 2006 at 07:48:50AM -0700, Matt Stupple
wrote:
> [Perhaps someone could rename this list to dtrace-matt-problems-discuss?]
> 
> If I run this script against my binary (which contains a USDT probe called
''concurrentq-latency''):
> 
> :::
> / probename == "concurrentq-latency" /
> {
> 	printf("[%s]:[%s]:[%s]\n", probeprov, probefunc, probename);
> }
> 
> I get this output:
> 
> dtrace: script ''testq.d'' matched 46056 probes
> dtrace: pid 26257 has exited
> CPU     ID                    FUNCTION:NAME
>   2  46076 dequeue_thread:concurrentq-latency
[tests26257]:[dequeue_thread]:[concurrentq-latency]
> 
> However, if I try to specify the probe in the ''normal''
fashion:
> 
> :::concurrentq-latency
> {
> 	printf("[%s]:[%s]:[%s]\n", probeprov, probefunc, probename);
> }
> 
> I get this instead:
> 
> dtrace: failed to compile script testq.d: line 1: probe description
:::concurrentq-latency does not match any probes
> 
> How does dtrace determine the existence of probes within a given binary,
and what might cause it not to ''see'' probes which *do* in fact
exist...?
> 
> Thanks,
> 
> Matt.
>  
>  
> This message posted from opensolaris.org
> _______________________________________________
> dtrace-discuss mailing list
> dtrace-discuss at opensolaris.org
-- 
Adam Leventhal, Solaris Kernel Development       http://blogs.sun.com/ahl

For general reference, here''s the upshot of Adam''s
investigation of my problem:

*****
I figured it out and it''s a bug in the DTrace library. You can work
around
the problem by using the -Z option to dtrace(1M). I''ve filed this bug:

  6474431 libdtrace can only handle one USDT provider per load object

---8<---
[ahl 9.22.2006]

When using the -c or -p options to dtrace(1M), the command uses
libdtrace to examine the traced process to see if there are any USDT
providers. It then forces them to be loaded on behalf of the process.
The problem is that libdtrace does this by looking up the symbol
__SUNW_dof using Pxlookup_by_name() so if there are multiple USDT
providers (and therefore multiple __SUNW_dof symbols) it will get one
(more or less at random) and miss the others. The library needs to
iterate over all symbols or libproc needs to provide a mechanism for
iterating over all symbols that have the same name.
*** (#1 of 1): 2006-09-22 16:17:17 PDT adam.leventhal at sun.com
---8<---

Adam
 
 
This message posted from opensolaris.org