Provided by: systemtap-doc_5.0-2ubuntu1_amd64 bug

NAME

       error::pass2 - systemtap pass-2 errors

DESCRIPTION

       Errors that occur during pass 2 (elaboration) can have a variety of causes.  Common types include:

       missing debuginfo
              The  script  requires  debuginfo  to  resolve  a  probe  point,  but  could  not  find  any.   See
              error::dwarf(7stap) and warning::debuginfo(7stap) for more details.

       unavailable probe point classes
              Some types of probe points are only available  on  certain  system  versions,  architectures,  and
              configurations.   For  example,  user-space  process.*   probes  may  require  utrace  or  uprobes
              capability in the kernel for this architecture.

       unavailable probe points
              Some probe points may be individually unavailable even when their class  is  fine.   For  example,
              kprobe.function("foobar")  may  fail  if  function  foobar  does not exist in the kernel any more.
              Debugging or symbol data may be absent for some types of .function or .statement probes; check for
              availability of debuginfo.  Try the stap-prep program  to  download  possibly-required  debuginfo.
              Use  a  wildcard  parameter  such  as  stap -l 'kprobe.function("*foo*")' to locate still-existing
              variants.  Use ! or ?  probe point suffixes to denote optional /  preferred-alternatives,  to  let
              the working parts of a script continue.

       typos  There  might  be  a  spelling  error in the probe point name ("sycsall" vs.  "syscall").  Wildcard
              probes may not find a match at all in the tapsets.  Recheck the names using  stap  -l  PROBEPOINT.
              Another  common  mistake  is  to  use the .  operator instead of the correct -> when dereferencing
              context variable subfields or pointers: $foo->bar->baz even if in C one would say foo->bar.baz.

       unavailable context variables
              Systemtap scripts often wish to refer to variables from the context of the probed  programs  using
              $variable  notation.   These  variables  may not always be available, depending on versions of the
              compiler, debugging/optimization flags used, architecture, etc.  Use stap -L  PROBEPOINT  to  list
              available  context  variables  for  given  probes.   Use the @defined() expression to test for the
              resolvability of a context variable expression.  Consider using the stap --skip-badvars option  to
              silently  replace  misbehaving  context  variable expressions with zero.  Experiment with the stap
              --prologue-searching option.

       module cache inconsistencies
              Occasionally,  the  systemtap  module  cache  ($HOME/.systemtap/cache)  might   contain   obsolete
              information  from  a  prior  system  configuration/version, and produce false results as systemtap
              attempts to reuse it.  Retrying with  stap  --poison-cache  ...   forces  new  information  to  be
              generated.  Note: this should not happen and likely represents a systemtap bug.  Please report it.

GATHERING MORE INFORMATION

       Increasing the verbosity of pass-2 with an option such as --vp 02 can help pinpoint the problem.

SEE ALSO

       stap(1),
       stap-prep(1),
       stapprobes(3stap),
       probe::*(3stap),
       error::dwarf(7stap),
       error::inode-uprobes(7stap),
       warning::debuginfo(7stap),
       error::reporting(7stap)

                                                                                             ERROR::PASS2(7stap)