Peter,
Speculations are best for logging a short sequence of events triggered
by some final event. One problem with your script is that you are trying
to log everything, and are never discarding anything. So if you really
need to log everything, a speculation is not appropriate.
If you only want to know which function made the change you can do this
easily without a speculation. For example ...
proc:::exec-success
/ execname == "dtlogin" /
{
self->proc = curthread->t_procp;
self->task = self->proc->p_task;
self->proj = self->task->tk_proj;
}
syscall:::entry
/ self->proc /
{
self->refresh = 1;
}
syscall:::return
/ self->refresh /
{
self->proc = curthread->t_procp;
self->task = self->proc->p_task;
self->proj = self->task->tk_proj;
self->refresh = 0;
}
fbt:::entry,fbt:::return
/ self->proc && self->proj->kpj_data.kpd_crypto_mem == 0/
{
self->cmem = self->proj->kpj_data.kpd_crypto_mem;
printf("\ncurthread = %p, proc = %p, ", curthread,
self->proc);
printf("pid = %d, task = %p, ", pid, self->task);
printf("proj = %p, cmem = %X\n", self->proj,
self->cmem);
self->proc = 0;
exit(0);
}
Although I''ve tried to reduce the impact on the system, enabling every
FBT entry and return probe will have a huge effect on system
performance. But we don''t have to be so heavy handed. A quick grok of
the OpenSolaris source reveals less than a dozen lines of code that
modify kpd_crypto_mem (assuming no bzero() calls etc) so you set up a
few specific FBT probes for those specific cases.
Note the use of thread local storage for intermediate values (your
version wasn''t thread safe, due to the use of globals). Note also that
my predicates are simpler, and that I''ve assumed that self->proj
only
changes after a syscall (I haven''t bothered to find out which ones).
Hope this helps,
Phil
Peter Shoults wrote:> Hi,
>
> I am trying to use speculative tracing for the first time. I have a
> condition that I would like to catch when a member of a data structure
> goes "negative". I wrote the following dtrace script and it
never gives
> me any information at all unless the very last routine is uncommented.
> When that is uncommented, I do see quite a lot of data which makes be
> believe that self->crypto_mem does get to zero, which I know it will
> have a value of zero. I think I have coded this up right, so I would
> have expected when we get to the commit statement, the commit should
> output data. Maybe that is a wrong assumption? But even control-c,
> which outputs data if the last routine is uncommented, does not after
> the commit. I figure I have to be doing something wrong, but can not
> see it. Been following the example in the guide - thought I had it right.
>
> Peter
>