`range end index out of range` error in pyo3-introspection

[abrisco]

Bug Description

I'm trying to use the new pyo3-introspection crate (introduced in #3977) to generate stubs and ran into a panic when trying this on my MacOS arm64 machine. The binary I wrote to try and generate stubs is @rules_pyo3//pyo3/private/stubgen.rs. The pyo3 module is being built optimized but I did try debug and got the same result.

Steps to Reproduce

1. Clone https://github.com/abrisco/rules_pyo3/tree/stubgen
2. Run bazel build //pyo3/private/tests/string_sum:string_sum

Backtrace

thread 'main' panicked at external/+rust_ext+rpyo3c__pyo3-introspection-0.25.0-dev/src/introspection.rs:214:38:
range end index 9007199255016033 out of range for slice of length 478128
stack backtrace:
   0: _rust_begin_unwind
   1: core::panicking::panic_fmt
   2: core::slice::index::slice_end_index_len_fail::do_panic::runtime
   3: core::slice::index::slice_end_index_len_fail
   4: pyo3_introspection::introspection::read_symbol_value_with_ptr_and_len
   5: pyo3_introspection::introspection::find_introspection_chunks_in_macho
   6: pyo3_introspection::introspection::find_introspection_chunks_in_binary_object
   7: pyo3_introspection::introspection::introspect_cdylib
   8: stubgen::main
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.

Your operating system and version

MacOS arm64

Your Python version (python --version)

Python 3.11.11

Your Rust version (rustc --version)

1.85.1 (4eb161250 2025-03-15)

Your PyO3 version

0.25.0-dev

How did you install python? Did you use a virtualenv?

None

Additional Info

I know my steps to repro are Bazel but I can work with someone to get more canonical repro steps. My hope was that I could provide enough info so that the issue might be obvious.

[abrisco]

cc @Tpt I was excited to try this but unfortunately found this issue. Anything jump out at you?

[Tpt]

It looks like a bug when extracting the data from the Mach-O binary, offsets are wrong and it leads to a too large slice being used. What is weird is that I am also using an ARM Mac and never encountered this issue.

An hypothesis: I have not carefully tested introspection with modules declared using functions but mostly using inline Rust module, it's maybe related to that.

[abrisco]

An hypothesis: I have not carefully tested introspection with modules declared using functions but mostly using inline Rust module, it's maybe related to that.

That's definitely what all my tests are doing
@rules_pyo3//pyo3/private/tests/string_sum/string_sum.rs

I can try migrating though and see what happens.

[abrisco]

I get the same results using

use pyo3::prelude::*;

#[pymodule]
mod string_sum {
    use super::*;

    #[pyfunction]
    fn sum_as_string(a: usize, b: usize) -> PyResult<String> {
        Ok((a + b).to_string())
    }
}

thread 'main' panicked at external/+rust_ext+rpyo3c__pyo3-introspection-0.25.0-dev/src/introspection.rs:214:38:
range end index 9007199255016033 out of range for slice of length 478128
stack backtrace:
   0: _rust_begin_unwind
   1: core::panicking::panic_fmt
   2: core::slice::index::slice_end_index_len_fail::do_panic::runtime
   3: core::slice::index::slice_end_index_len_fail
   4: pyo3_introspection::introspection::read_symbol_value_with_ptr_and_len
   5: pyo3_introspection::introspection::find_introspection_chunks_in_macho
   6: pyo3_introspection::introspection::find_introspection_chunks_in_binary_object
   7: pyo3_introspection::introspection::introspect_cdylib
   8: stubgen::main
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.

[Tpt]

Thank you! There is definitely a bug in the introspection code. I am going to have a look at it

[abrisco]

In case it helps, this is the raw dylib I compiled: libstring_sum.dylib.zip

It's the results of @rules_pyo3//pyo3/private/tests/string_sum/string_sum.rs

The invocation subcommand for the dylib was:

SUBCOMMAND: # //pyo3/private/tests/string_sum:string_sum_shared [action 'Compiling Rust cdylib string_sum_shared (1 files)', configuration: 33e5b2660f1fb4e2c0cdf0acef8c23d99e605b0664b8c7cbdce0a5e0796b0c6b, execution platform: @@platforms//host:host, mnemonic: Rustc]
(cd /private/var/tmp/_bazel_andrebrisco/ce429a188779bd65cb62a862d1866901/execroot/_main && \
  exec env - \
    CARGO_CFG_TARGET_ARCH=aarch64 \
    CARGO_CFG_TARGET_OS=macos \
    CARGO_CRATE_NAME=string_sum \
    CARGO_MANIFEST_DIR='${pwd}/pyo3/private/tests/string_sum' \
    CARGO_PKG_AUTHORS='' \
    CARGO_PKG_DESCRIPTION='' \
    CARGO_PKG_HOMEPAGE='' \
    CARGO_PKG_NAME=string_sum_shared \
    CARGO_PKG_VERSION=0.0.0 \
    CARGO_PKG_VERSION_MAJOR=0 \
    CARGO_PKG_VERSION_MINOR=0 \
    CARGO_PKG_VERSION_PATCH=0 \
    CARGO_PKG_VERSION_PRE='' \
    REPOSITORY_NAME='' \
    ZERO_AR_DATE=1 \
  bazel-out/darwin_arm64-opt-exec-ST-d57f47055a04/bin/external/rules_rust+/util/process_wrapper/process_wrapper --arg-file bazel-out/darwin_arm64-opt/bin/external/+rust_ext+rpyo3c__libc-0.2.171/_bs.linksearchpaths --arg-file bazel-out/darwin_arm64-opt/bin/external/+rust_ext+rpyo3c__memoffset-0.9.1/_bs.linksearchpaths --arg-file bazel-out/darwin_arm64-opt/bin/external/+rust_ext+rpyo3c__pyo3-0.25.0-dev/_bs.linksearchpaths --arg-file bazel-out/darwin_arm64-opt/bin/external/+rust_ext+rpyo3c__pyo3-ffi-0.25.0-dev/_bs.linksearchpaths --subst 'pwd=${pwd}' -- bazel-out/darwin_arm64-opt/bin/external/rules_rust++rust+rust_macos_aarch64__aarch64-apple-darwin__stable_tools/rust_toolchain/bin/rustc pyo3/private/tests/string_sum/string_sum.rs '--crate-name=string_sum' '--crate-type=cdylib' '--error-format=human' '--out-dir=bazel-out/darwin_arm64-opt/bin/pyo3/private/tests/string_sum' '--codegen=opt-level=3' '--codegen=debuginfo=0' '--codegen=strip=debuginfo' '--remap-path-prefix=${pwd}=' '--emit=dep-info,link' '--color=always' '--target=aarch64-apple-darwin' -L bazel-out/darwin_arm64-opt/bin/external/rules_rust++rust+rust_macos_aarch64__aarch64-apple-darwin__stable_tools/rust_toolchain/lib/rustlib/aarch64-apple-darwin/lib '--edition=2021' '-Cembed-bitcode=no' '--codegen=linker=external/rules_cc++cc_configure_extension+local_config_cc/cc_wrapper.sh' '--codegen=link-arg=-shared' '--codegen=link-arg=-mmacosx-version-min=15.2' '--codegen=link-arg=-no-canonical-prefixes' '--codegen=link-arg=-fobjc-link-runtime' '--codegen=link-arg=-Xlinker' '--codegen=link-arg=-rpath' '--codegen=link-arg=-Xlinker' '--codegen=link-arg=@loader_path/../../../../_solib_darwin_arm64/_U_A_Arules_Upython++python+python_U3_U11_Uaarch64-apple-darwin_S_S_Clibpython___Ulib' '--codegen=link-arg=-headerpad_max_install_names' '--codegen=link-arg=-Wl,-dead_strip' '--codegen=link-arg=-lc++' '--codegen=link-arg=-lm' '-Lnative=bazel-out/darwin_arm64-opt/bin/_solib_darwin_arm64/_U_A_Arules_Upython++python+python_U3_U11_Uaarch64-apple-darwin_S_S_Clibpython___Ulib' '-ldylib=python3.11' '--extern=pyo3=bazel-out/darwin_arm64-opt/bin/external/+rust_ext+rpyo3c__pyo3-0.25.0-dev/libpyo3-8428150.rlib' '-Ldependency=bazel-out/darwin_arm64-opt/bin/external/+rust_ext+rpyo3c__cfg-if-1.0.0' '-Ldependency=bazel-out/darwin_arm64-opt/bin/external/+rust_ext+rpyo3c__libc-0.2.171' '-Ldependency=bazel-out/darwin_arm64-opt/bin/external/+rust_ext+rpyo3c__memoffset-0.9.1' '-Ldependency=bazel-out/darwin_arm64-opt/bin/external/+rust_ext+rpyo3c__once_cell-1.21.3' '-Ldependency=bazel-out/darwin_arm64-opt/bin/external/+rust_ext+rpyo3c__pyo3-ffi-0.25.0-dev' '-Ldependency=bazel-out/darwin_arm64-opt/bin/external/+rust_ext+rpyo3c__unindent-0.2.4' '-Ldependency=bazel-out/darwin_arm64-opt-exec-ST-d57f47055a04/bin/external/+rust_ext+rpyo3c__indoc-2.0.6' '-Ldependency=bazel-out/darwin_arm64-opt-exec-ST-d57f47055a04/bin/external/+rust_ext+rpyo3c__pyo3-macros-0.25.0-dev' '-Ldependency=bazel-out/darwin_arm64-opt/bin/external/+rust_ext+rpyo3c__pyo3-0.25.0-dev' '--sysroot=bazel-out/darwin_arm64-opt/bin/external/rules_rust++rust+rust_macos_aarch64__aarch64-apple-darwin__stable_tools/rust_toolchain')
# Configuration: 33e5b2660f1fb4e2c0cdf0acef8c23d99e605b0664b8c7cbdce0a5e0796b0c6b
# Execution platform: @@platforms//host:host
# Runner: sandbox-fallback

[Tpt]

I have investigating this a bit, it seems the symbol value found by the MachO parser is not the correct one because reading it yield to a very large pointer, converted to a very large index.

I have not reproduced this bug using regular cargo, it's possible that Cargo+Bazel and plain Cargo do not output MachO file with the same exact structure and I made a wrong assumption when parsing MachO files.

[abrisco]

This is the debug print of the command which spawns rustc

Command {
    program: "bazel-out/darwin_arm64-opt/bin/external/rules_rust++rust+rust_macos_aarch64__aarch64-apple-darwin__stable_tools/rust_toolchain/bin/rustc",
    args: [
        "bazel-out/darwin_arm64-opt/bin/external/rules_rust++rust+rust_macos_aarch64__aarch64-apple-darwin__stable_tools/rust_toolchain/bin/rustc",
        "pyo3/private/tests/string_sum/string_sum.rs",
        "--crate-name=string_sum",
        "--crate-type=cdylib",
        "--error-format=human",
        "--out-dir=bazel-out/darwin_arm64-opt/bin/pyo3/private/tests/string_sum",
        "--codegen=opt-level=3",
        "--codegen=debuginfo=0",
        "--codegen=strip=debuginfo",
        "--remap-path-prefix=/private/var/tmp/_bazel_userprofile/ce429a188779bd65cb62a862d1866901/sandbox/darwin-sandbox/19/execroot/_main=",
        "--emit=dep-info,link",
        "--color=always",
        "--target=aarch64-apple-darwin",
        "-L",
        "bazel-out/darwin_arm64-opt/bin/external/rules_rust++rust+rust_macos_aarch64__aarch64-apple-darwin__stable_tools/rust_toolchain/lib/rustlib/aarch64-apple-darwin/lib",
        "--edition=2021",
        "-Cembed-bitcode=no",
        "--codegen=linker=external/rules_cc++cc_configure_extension+local_config_cc/cc_wrapper.sh",
        "--codegen=link-arg=-shared",
        "--codegen=link-arg=-mmacosx-version-min=15.2",
        "--codegen=link-arg=-no-canonical-prefixes",
        "--codegen=link-arg=-fobjc-link-runtime",
        "--codegen=link-arg=-Xlinker",
        "--codegen=link-arg=-rpath",
        "--codegen=link-arg=-Xlinker",
        "--codegen=link-arg=@loader_path/../../../../_solib_darwin_arm64/_U_A_Arules_Upython++python+python_U3_U11_Uaarch64-apple-darwin_S_S_Clibpython___Ulib",
        "--codegen=link-arg=-headerpad_max_install_names",
        "--codegen=link-arg=-Wl,-dead_strip",
        "--codegen=link-arg=-lc++",
        "--codegen=link-arg=-lm",
        "-Lnative=bazel-out/darwin_arm64-opt/bin/_solib_darwin_arm64/_U_A_Arules_Upython++python+python_U3_U11_Uaarch64-apple-darwin_S_S_Clibpython___Ulib",
        "-ldylib=python3.11",
        "--extern=pyo3=bazel-out/darwin_arm64-opt/bin/external/+rust_ext+rpyo3c__pyo3-0.25.0-dev/libpyo3-8428150.rlib",
        "-Ldependency=bazel-out/darwin_arm64-opt/bin/external/+rust_ext+rpyo3c__cfg-if-1.0.0",
        "-Ldependency=bazel-out/darwin_arm64-opt/bin/external/+rust_ext+rpyo3c__libc-0.2.171",
        "-Ldependency=bazel-out/darwin_arm64-opt/bin/external/+rust_ext+rpyo3c__memoffset-0.9.1",
        "-Ldependency=bazel-out/darwin_arm64-opt/bin/external/+rust_ext+rpyo3c__once_cell-1.21.3",
        "-Ldependency=bazel-out/darwin_arm64-opt/bin/external/+rust_ext+rpyo3c__pyo3-ffi-0.25.0-dev",
        "-Ldependency=bazel-out/darwin_arm64-opt/bin/external/+rust_ext+rpyo3c__unindent-0.2.4",
        "-Ldependency=bazel-out/darwin_arm64-opt-exec-ST-d57f47055a04/bin/external/+rust_ext+rpyo3c__indoc-2.0.6",
        "-Ldependency=bazel-out/darwin_arm64-opt-exec-ST-d57f47055a04/bin/external/+rust_ext+rpyo3c__pyo3-macros-0.25.0-dev",
        "-Ldependency=bazel-out/darwin_arm64-opt/bin/external/+rust_ext+rpyo3c__pyo3-0.25.0-dev",
        "--sysroot=bazel-out/darwin_arm64-opt/bin/external/rules_rust++rust+rust_macos_aarch64__aarch64-apple-darwin__stable_tools/rust_toolchain",
    ],
    env: CommandEnv {
        clear: true,
        vars: {
            "CARGO_CFG_TARGET_ARCH": Some(
                "aarch64",
            ),
            "CARGO_CFG_TARGET_OS": Some(
                "macos",
            ),
            "CARGO_CRATE_NAME": Some(
                "string_sum",
            ),
            "CARGO_MANIFEST_DIR": Some(
                "/private/var/tmp/_bazel_userprofile/ce429a188779bd65cb62a862d1866901/sandbox/darwin-sandbox/19/execroot/_main/pyo3/private/tests/string_sum",
            ),
            "CARGO_PKG_AUTHORS": Some(
                "",
            ),
            "CARGO_PKG_DESCRIPTION": Some(
                "",
            ),
            "CARGO_PKG_HOMEPAGE": Some(
                "",
            ),
            "CARGO_PKG_NAME": Some(
                "string_sum_shared",
            ),
            "CARGO_PKG_VERSION": Some(
                "0.0.0",
            ),
            "CARGO_PKG_VERSION_MAJOR": Some(
                "0",
            ),
            "CARGO_PKG_VERSION_MINOR": Some(
                "0",
            ),
            "CARGO_PKG_VERSION_PATCH": Some(
                "0",
            ),
            "CARGO_PKG_VERSION_PRE": Some(
                "",
            ),
            "REPOSITORY_NAME": Some(
                "",
            ),
            "RULES_RUST_PROCESS_WRAPPER_DEBUG": Some(
                "1",
            ),
            "TMPDIR": Some(
                "/var/folders/h4/_xm41cq11v90znmm9dz87wdc0000gn/T/",
            ),
            "ZERO_AR_DATE": Some(
                "1",
            ),
            "__CF_USER_TEXT_ENCODING": Some(
                "0x1F5:0x0:0x0",
            ),
        },
    },
    stdout: Some(
        Inherit,
    ),
    stderr: Some(
        MakePipe,
    ),
}

[abrisco]

@Tpt Would the name of the library have an impact? In the Bazel infrastructure I built I append _shared to library and then make a symlink of the clean name back to this file. Could that have an impact here?

[Tpt]

Thank you for the trace!

I don't think the library name has an impact, pyo3-introspection parses the Mach-O binary so if it can open it (and it does) then things shoud be good

[abrisco]

I did more poking but I don't think I understand the original implementation. There is data embedded in sections of some data header? Or are all symbols parsed and then a lookup into the binary occurs? The latter sounds like it'd be sensitve to stripping and optimizations so assuming not that.

Some more data that might be useful though, println!("{:#?}", macho); output of the Mach::Binary struct:

• libstring_sum.dylib.debug_log.txt
• pyo3_pytests.cpython-311-darwin.so.debug_log.txt

[Tpt]

There is data embedded in sections of some data header?

Yes! PyO3 macros generates statics with metadata about the exposed elements (module, class, function...) and then the pyo3-introspection look for them.
These statics are &str hence, in the binary the symbol value is a pair (ptr_to_the_actual_string, actual_string_len). The panic happens when trying to go to the ptr_to_the_actual_string value in the binary.

[abrisco]

Something I noticed, the Bazel compiled binary has no __la_symbol_ptr sections where the Maturin built one does.

developer.apple.com

Section	Description
...	...
__la_symbol_ptr	“Lazy” symbol pointers. Symbol pointers for each undefined function called by the executable.
...	...