Hi Roman,
User level tracing (with the pid provider) is being removed during fork
by design. In theory, the pid provider could create a new provider when a
traced process forks and it''s probes could effectively start out
enabled,
but there are some trickier issues. For example, if you''ve specified
that
you want to trace, say, pid123::malloc:entry, DTrace needs to figure out
that pid123 really means process 123 and any children. Tricky. An obvious
solution would be to use -p or -c and have pid$target expand to something
more complex, but then consider the situation where you had a predicate
of the form /pid == $target/...
The point is, we realize the limitation, but it''s a very tricky and
intricate problem (more from the greater DTrace perspective than in terms
of just the pid provider). We have some ideas for how to solve the problem,
but an implementation is a ways off.
Adam
On Thu, Apr 20, 2006 at 06:52:02PM -0700, Roman Shaposhnick
wrote:> Guys,
>
> I''ve been trying to instrument a binary which does quite a lot
> of fork()''ing (but NO exec()''ing) just to discover that
user
> level instrumentation doesn''t seem to be surviving the fork():
>
http://cvs.opensolaris.org/source/xref/on/usr/src/uts/common/dtrace/fasttrap.c#383
>
> Now, the question I have is -- why an unconditional removal
> of instrumentation from a child ? Is it an explicit design
> decision/limitation or just a lack of option ?
>
> Thanks,
> Roman.
>
> P.S. Please Cc me, I''m not on the list...
> _______________________________________________
> dtrace-discuss mailing list
> dtrace-discuss at opensolaris.org
--
Adam Leventhal, Solaris Kernel Development http://blogs.sun.com/ahl