Provided by: systemtap-doc_3.1-3ubuntu0.1_all 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)