dtrace discuss - Jul 2005 - confused about pid provider entry probes

I found that in my program, the probe description

    pid$target::gethostbyname:entry {}

matched 4 probes, but they didn''t fire, and none of them were the one I
wanted.  Instead I had to write:

    pid$target:libnsl.so:gethostbyname:entry {}

Why?  It is somewhat strenuous to chase down the module for all the functions I
want to trace.

BACKGROUND

I was trying to find all the places in my program where thread unsafe library
functions were called.  So I wrote a dtrace script (gethostbyname.d)

    pid$target::gethostbyname:entry {}

Then I ran my program (a modified Tcl shell) and called the [socket] command
which I know to call gethostbyname().  The probe did not fire, so I ran with
''-l''

$ dtrace -l -s gethostbyname.d -p 26591
   ID   PROVIDER            MODULE                          FUNCTION NAME
37403   pid26591      libcrypto.so                           dlclose entry
37413   pid26591         libc.so.1                           dlclose entry
37414   pid26591        libdl.so.1                           dlclose entry
37415   pid26591         libtrf.so                           dlclose entry

These all appear to be *callers* of the function but not providers.  When I
changed my probe description to

    pid$target:libnsl.so:gethostbyname:entry {}

then I get the one probe, and it fires.

$ dtrace -l -s forum-question.d -p 26591
   ID   PROVIDER            MODULE                          FUNCTION NAME
37402   pid26591       libnsl.so.1                     gethostbyname entry
This message posted from opensolaris.org

Hi Ken,

This is due to two interacting bugs in libdtrace. The more important of
the two has been fixed so you shouldn''t see problem in Solaris Express
or
OpenSolaris. This fix will also be in an update to Solaris 10.

The problem that''s been fixed is that libdtrace was picking up UNDEF
symbols when the module name is unspecified or contains wild card
characters. If you''re interested, here is a link to the bug:

  http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6223603

The other issue has to do with functions having many different names
due to weak binding aliases. As it''s rather involved and your specific
issue has been addressed in the other bug, I''ll save that gruesome
story
for another day.

Adam

On Fri, Jul 08, 2005 at 06:49:37AM -0700, Ken Cox wrote:
> I found that in my program, the probe description
> 
>     pid$target::gethostbyname:entry {}
> 
> matched 4 probes, but they didn''t fire, and none of them were the
one I wanted.  Instead I had to write:
> 
>     pid$target:libnsl.so:gethostbyname:entry {}
> 
> Why?  It is somewhat strenuous to chase down the module for all the
functions I want to trace.
> 
> BACKGROUND
> 
> I was trying to find all the places in my program where thread unsafe
library functions were called.  So I wrote a dtrace script (gethostbyname.d)
> 
>     pid$target::gethostbyname:entry {}
> 
> Then I ran my program (a modified Tcl shell) and called the [socket]
command which I know to call gethostbyname().  The probe did not fire, so I ran
with ''-l''
> 
> $ dtrace -l -s gethostbyname.d -p 26591
>    ID   PROVIDER            MODULE                          FUNCTION NAME
> 37403   pid26591      libcrypto.so                           dlclose entry
> 37413   pid26591         libc.so.1                           dlclose entry
> 37414   pid26591        libdl.so.1                           dlclose entry
> 37415   pid26591         libtrf.so                           dlclose entry
> 
> These all appear to be *callers* of the function but not providers.  When I
changed my probe description to
> 
>     pid$target:libnsl.so:gethostbyname:entry {}
> 
> then I get the one probe, and it fires.
> 
> $ dtrace -l -s forum-question.d -p 26591
>    ID   PROVIDER            MODULE                          FUNCTION NAME
> 37402   pid26591       libnsl.so.1                     gethostbyname entry
> 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