---
name: "error::pass2"
section: "7stap"
platform: "linux"
package: "systemtap"
version: "5.6-1"
release: "Arch Linux 2026-11-01"
platforms: ["linux"]
url: "https://new.carta.tech/error::pass2"
---

# error::pass2(7stap)

systemtap pass-2 errors

## 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)](/error::dwarf/7stap.md) and [*warning::debuginfo*(7stap)](/warning::debuginfo/7stap.md) 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)
```