dtrace discuss - Nov 2005 - Identifying anonymous errors, disabling anonymous tracing

When I booted with anonymous enablings, I saw

  ...
  NOTICE: enabling probe 8 (syscall:::return)
  NOTICE: enabling probe 9 (syscall:::return)
  ...

Then when I claimed the data, dtrace said

  dtrace: error on enabled probe ID 607 (ID 148: syscall::lwp_park:return):
invalid address (0xfe67a000) in action #1
  dtrace: error on enabled probe ID 607 (ID 148: syscall::lwp_park:return):
invalid address (0xfce7a000) in action #1
  ...

How can I tell which probe enabling generated the errors?  If ''enabled
probe ID'' is unique to each enabling, would it be unreasonable for the
NOTICE messages to print them?

Secondly, when I claimed the data, were the probes disabled?


David

On Tue, Nov 01, 2005 at 12:32:13PM -0800, David Bustos
wrote:
> When I booted with anonymous enablings, I saw
> 
>   ...
>   NOTICE: enabling probe 8 (syscall:::return)
>   NOTICE: enabling probe 9 (syscall:::return)
>   ...
> 
> Then when I claimed the data, dtrace said
> 
>   dtrace: error on enabled probe ID 607 (ID 148: syscall::lwp_park:return):
invalid address (0xfe67a000) in action #1
>   dtrace: error on enabled probe ID 607 (ID 148: syscall::lwp_park:return):
invalid address (0xfce7a000) in action #1
>   ...
> 
> How can I tell which probe enabling generated the errors?  If
''enabled
> probe ID'' is unique to each enabling, would it be unreasonable for
the
> NOTICE messages to print them?
The problem is that there is one EPID for every {enabling, matched probe}
pair;  so there are ~229 for probe 8, and the same number for probe 9.  It
might make sense to print out the "probe #" in the error message,
though.
> Secondly, when I claimed the data, were the probes disabled?
The probes will become disabled when the claiming dtrace process exits.

Using ''dtrace -ae'' will cause dtrace to exit immediately after
claiming and
printing anonymous state.

Cheers,
- jonathan

-- 
Jonathan Adams, Solaris Kernel Development