dtrace discuss - Dec 2007 - 6618705: p*d123 doesn''t cause pid probes to be created

I''ve started looking at this bug (the fix is fairly trivial.)  The bug
description references dt_pid_create_probes_module(), but there are
actually two places in which this is a problem, the other being
dt_pid_create_probes().  The latter appears to be the normal code path
for this bug.  This path seems pretty easy to test:

Without fix:

# dtrace -F -n ''p*d$target:::entry,p*d$target:::return'' -c
/bin/ls > /dev/null
dtrace: invalid probe specifier
p*d$target:::entry,p*d$target:::return: probe description
p*d628811:::entry does not match any probes
#

With fix:

# dtrace -F -n ''p*d$target:::entry,p*d$target:::return'' -c
/bin/ls > /dev/null
dtrace: description ''p*d$target:::entry,p*d$target:::return''
matched
10871 probes
dtrace: pid 628846 has exited
#

The latter path is a bit more interesting, though, as it''s related to
rtld events.  What I''ve come up with to test this is this:

p*d$1::malloc:entry
{
        printf("%s\n",probemod);
}

And run this against a program executing this code:

int
go(void)
{
        void *handle;
        void *(*umem_malloc)(size_t);

        (void) malloc(20);

        if ((handle = dlopen("/usr/lib/libumem.so", RTLD_NOW)) ==
NULL) {
                exit(1);
        }

        if ((umem_malloc = (void *(*)(size_t)) dlsym(handle,
"malloc"))
            == NULL) {
                exit(1);
        }

        (void) (*umem_malloc)(20);

        (void) dlclose(handle);
}

I''ll see libc.so.1 reported for the first malloc() call and
libumem.so.1 reported for the explicit use of libumem''s malloc().

Unfortunately, I also get a number of reports of LM1`ld.so.1 which I''m
just hackishly ignoring.

Is there a better (or cleaner) way I could be testing this?

Thanks,
Chad Mynhier

On Mon, Dec 10, 2007 at 04:13:55PM -0500, Chad Mynhier
wrote:
> I''ll see libc.so.1 reported for the first malloc() call and
> libumem.so.1 reported for the explicit use of libumem''s malloc().
> 
> Unfortunately, I also get a number of reports of LM1`ld.so.1 which
I''m
> just hackishly ignoring.
> 
> Is there a better (or cleaner) way I could be testing this?
I think I''d choose a symbol of my own devising, and you might want to
break
this into two tests: one to test that you match p*d123::malloc:entry and
another to make sure a symbol in an object that you open is properly
matched.

Adam

-- 
Adam Leventhal, FishWorks                        http://blogs.sun.com/ahl