ERROR::PASS2(7stap) ERROR::PASS2(7stap)

# [NAME](#NAME)

error::pass2 - systemtap pass-2 errors

# [DESCRIPTION](#DESCRIPTION)

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

[missing debuginfo](#missing)

The script requires debuginfo to resolve a probe point, but could not find any. See [*error::dwarf*(7stap)](/man/enterprise-packages/systemtap/error::dwarf.7stap) and [*warning::debuginfo*(7stap)](/man/enterprise-packages/systemtap/warning::debuginfo.7stap) for more details.

[unavailable probe point classes](#unavailable)

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](#unavailable~2)

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](#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](#unavailable~3)

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](#module)

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](#GATHERING_MORE_INFORMATION)

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

# [SEE ALSO](#SEE_ALSO)

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

---

Document: error::pass2(7stap) from systemtap 5.6-r0 (Chainguard OS)
Source: https://sourceware.org/git/systemtap.git