benfred/py-spy · critical

Both python and libpython are invalid.

Error message

Both python and libpython are invalid.

What it means

In get_interpreter_address, py-spy tries to locate the PyInterpreterState address first from the python binary's BSS and then from libpython's BSS. If both attempts return errors, err.expect() panics with "Both python and libpython are invalid.", meaning memory scanning for the interpreter state failed on every candidate module.

Source

Thrown at src/python_process_info.rs:439

    // try scanning the BSS section of the binary for things that might be the interpreterstate
    let err = if let Some(ref pb) = python_info.python_binary {
        match get_interpreter_address_from_binary(pb, &*python_info.maps, process, version) {
            Ok(addr) => return Ok(addr),
            err => Some(err),
        }
    } else {
        None
    };

    // Before giving up, try again if there is a libpython.so
    if let Some(ref lpb) = python_info.libpython_binary {
        info!("Failed to get interpreter from binary BSS, scanning libpython BSS");
        match get_interpreter_address_from_binary(lpb, &*python_info.maps, process, version) {
            Ok(addr) => Ok(addr),
            lib_err => err.unwrap_or(lib_err),
        }
    } else {
        err.expect("Both python and libpython are invalid.")
    }
}

// Gets the address of the main PyInterpreterState object from loaded symbols
fn get_interpreter_address_from_symbols<P>(
    python_info: &PythonProcessInfo,
    process: &P,
    version: &Version,
) -> Result<usize, Error>
where
    P: ProcessMemory,
{
    match version {
        Version {
            major: 3,
            minor: 13..=14,
            ..
        } => {

View on GitHub (pinned to 32080cc0c2)

Solutions

1. Upgrade py-spy to the latest version — support for new Python versions and build layouts is added over time.
2. Check for ptrace/memory-read restrictions (e.g. /proc/sys/kernel/yama/ptrace_scope, SELinux) and relax them or run as root.
3. Try profiling a stock interpreter build of the same Python version to confirm the custom build is the cause.
4. Fall back to sampling mode `py-spy record` with --nonblocking, or use a different profiler (e.g. pyinstrument in-process) if scanning can't work for that binary.

Example fix

// before: custom python build, old py-spy
py-spy dump --pid 1234  # panic: Both python and libpython are invalid.
// after
cargo install py-spy --locked  # or pip install py-spy --upgrade
sudo py-spy dump --pid 1234

# preflight: confirm a stock interpreter works on this host
py-spy dump --pid $(pgrep -f 'python3 -c .*idle_probe' || pgrep -x python3 | head -1) >/dev/null \
  || echo 'py-spy attach may be unsupported for this python build'

# attempt py-spy, fall back to an in-process profiler
sudo py-spy record --pid "$PID" -o p.svg || \
  python -m pyinstrument --renderer html -o p.html script.py

When it happens

Trigger: Attaching to a Python process where neither the main binary nor libpython yielded a valid interpreter address from BSS scanning — e.g. statically linked/ref-linked python, unusual builds, or restricted memory reads, when called from PythonSpy::new during dump/record.

Common situations: Profiling Python builds compiled without dynamic libpython or with nonstandard layouts, custom/embedded interpreters, selinux/ptrace restrictions causing failed memory reads, or version-mismatched py-spy vs an unusual Python version.

AI-assisted analysis of benfred/py-spy@32080cc0c2 (2026-09-05). Data as JSON: /api/errors/91ddcfdfdb06bee9. Report an issue: GitHub.