Provided by: systemtap-doc_4.6-2_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)