Using regexp for $pid in pid provider

[Vasanth Bhat]

Hi

Is it possible to use regular expression or wild cards or
blank in for the "$pid" in the probe description in the pid privider?

Suppose, if I want to monitor the libraries beling loaded dynamically
by different processes at runtime, and if I use the following probe
description, it doesn't seem to help.

pid*::dlopen:entry

OR

::dlopen:entry

Are there any approaches ( other provider) that need to be used, if we
want to monitor use of an library API across systemwide?

Thanks
Vasanth

[[e-mail]]

Think of it this way: the fbt provider instruments function boundaries in the kernel's address space; the pid provider does the same (and more) for processes. There is one kernel address space, but many process address spaces.

Implementing pid*::dlopen:entry has at least two huge implications: stopping and instrumenting every current process in the system; and instrumenting every new process address space over time (i.e. dealing with fork and exec). The impact on system performance would be huge.

Some have been creative in scripting around these challenges for small, specific sets of processes (e.g. tracing fork and exec syscalls, identifying target processes, stopping them, calling system() to start a pid provider scripts on them, etc) but you really have to want to do that :)

Another starting point for your current need might be to trace file opens across the system, predicating on file names that look like shared libraries.

----- Reply message -----
From: "Vasanth Bhat" <***@sun.com>
To: <dtrace-***@opensolaris.org>
Subject: [dtrace-discuss] Using regexp for $pid in pid provider
Date: Sat, Feb 5, 2011 08:59


Hi

Is it possible to use regular expression or wild cards or
blank in for the "$pid" in the probe description in the pid privider?

Suppose, if I want to monitor the libraries beling loaded dynamically
by different processes at runtime, and if I use the following probe
description, it doesn't seem to help.

pid*::dlopen:entry

OR

::dlopen:entry

Are there any approaches ( other provider) that need to be used, if we
want to monitor use of an library API across systemwide?

Thanks
Vasanth

[vasanth]

Thanks Phil.

--Vasanth

Post by ***@gmail.com
Think of it this way: the fbt provider instruments function boundaries
in the kernel's address space; the pid provider does the same (and
more) for processes. There is one kernel address space, but many
process address spaces.
stopping and instrumenting every current process in the system; and
instrumenting every new process address space over time (i.e. dealing
with fork and exec). The impact on system performance would be huge.
Some have been creative in scripting around these challenges for
small, specific sets of processes (e.g. tracing fork and exec
syscalls, identifying target processes, stopping them, calling
system() to start a pid provider scripts on them, etc) but you really
have to want to do that :)
Another starting point for your current need might be to trace file
opens across the system, predicating on file names that look like
shared libraries.
----- Reply message -----
Subject: [dtrace-discuss] Using regexp for $pid in pid provider
Date: Sat, Feb 5, 2011 08:59
Hi
Is it possible to use regular expression or wild cards or
blank in for the "$pid" in the probe description in the pid privider?
Suppose, if I want to monitor the libraries beling loaded dynamically
by different processes at runtime, and if I use the following probe
description, it doesn't seem to help.
pid*::dlopen:entry
OR
::dlopen:entry
Are there any approaches ( other provider) that need to be used, if we
want to monitor use of an library API across systemwide?
Thanks
Vasanth
_______________________________________________
dtrace-discuss mailing list

[Nico Williams]

Phil explains why you can't do quite what you want. But there is something
you can do: use the syscall or fbt providers to catch calls to mmap() (older
builds/releases) or mmapobj( (Solaris 11 Express), then stop() the victims
of interest if you need to trace them with the PID provider and use system()
to launch a dtrace instace to trace each new victim process (being careful
not to do this more than once per process, or to set the victim back to
running anyways).

Nico
--

[vasanth]

Thanks Nico.

I guess I will also have to look for open system call called before
mmap, as I need the path of the library that is being loaded
dynamically. I think my interest would be open or open64 followed by
mmap or mmap64 that uses the file descriptor returned by open.

Thanks
Vasanth

Post by Nico Williams
Phil explains why you can't do quite what you want. But there is
something you can do: use the syscall or fbt providers to catch calls
to mmap() (older builds/releases) or mmapobj( (Solaris 11 Express),
then stop() the victims of interest if you need to trace them with the
PID provider and use system() to launch a dtrace instace to trace each
new victim process (being careful not to do this more than once per
process, or to set the victim back to running anyways).
Nico
--