Segfault importing PyTorch on Linux (works on macOS)

[morrismeyer]

Bug Report:

Environment:

• GraalPy 25.0.1 (Oracle GraalVM Native)
• Linux x86_64 (Ubuntu)
• PyTorch 2.7.0 (built from source with GraalPy patches)

Minimal reproducer:

Download GraalPy 25.0.1 for Linux

wget https://github.com/oracle/graalpython/releases/download/graal-25.0.1/graalpy-25.0.1-linux-amd64.tar.gz
tar xzf graalpy-25.0.1-linux-amd64.tar.gz
./graalpy-25.0.1-linux-amd64/bin/graalpy -m venv venv
source venv/bin/activate
pip install torch==2.7.0
python -c "import torch._C" # SEGFAULT

Observed behavior:
Segfault during import torch._C (pybind11 module initialization).

Key observations:

• Native libraries load successfully via ctypes:
  import ctypes
  ctypes.CDLL('.../torch/lib/libtorch_python.so') # OK
• Crash occurs only when pybind11 module initializes
• Same build works on macOS aarch64, crashes on Linux x86_64

Crash location (from segfault handler):
com.oracle.svm.truffle.nfi.NativeSignature$ExecuteHelper.ffiCall(NativeSignature.java:157)
com.oracle.truffle.nfi.backend.libffi.LibFFIContext.executeNative(LibFFIContext.java:179)

Full crash output: (truncated)
[ [ SegfaultHandler caught a segfault in thread 0x00005e652f536c00 ] ]
siginfo: si_signo: 11, si_code: 128, si_addr: 0x0000000000000000

---

Morris Meyer - morris@surfworks.energy

[morrismeyer]

(.pytorch-venv) actions@mark1nuc:~/surfworks/graalpyjvmtest$ wget https://github.com/oracle/graalpython/releases/download/graal-25.0.1/graalpy-jvm-25.0.1-linux-amd64.tar.gz
--2026-01-10 20:03:46-- https://github.com/oracle/graalpython/releases/download/graal-25.0.1/graalpy-jvm-25.0.1-linux-amd64.tar.gz
Resolving github.com (github.com)... 140.82.114.4
Connecting to github.com (github.com)|140.82.114.4|:443... connected.
HTTP request sent, awaiting response... 302 Found
Location: https://release-assets.githubusercontent.com/github-production-release-asset/129883600/ffa9554c-f1c0-49b5-b6fa-dad10a0f4385?sp=r&sv=2018-11-09&sr=b&spr=https&se=2026-01-11T01%3A50%3A20Z&rscd=attachment%3B+filename%3Dgraalpy-jvm-25.0.1-linux-amd64.tar.gz&rsct=application%2Foctet-stream&skoid=96c2d410-5711-43a1-aedd-ab1947aa7ab0&sktid=398a6654-997b-47e9-b12b-9515b896b4de&skt=2026-01-11T00%3A50%3A17Z&ske=2026-01-11T01%3A50%3A20Z&sks=b&skv=2018-11-09&sig=V5AdaVgBRMpLE6nzkqW74VmlYXVg6A4iWlH1XvL1NVI%3D&jwt=eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmVsZWFzZS1hc3NldHMuZ2l0aHVidXNlcmNvbnRlbnQuY29tIiwia2V5Ijoia2V5MSIsImV4cCI6MTc2ODA5NzAyNiwibmJmIjoxNzY4MDkzNDI2LCJwYXRoIjoicmVsZWFzZWFzc2V0cHJvZHVjdGlvbi5ibG9iLmNvcmUud2luZG93cy5uZXQifQ.KjSG0gtg1SQuvoVffian3snWg2orV-Tbx1kqNiNRZKg&response-content-disposition=attachment%3B%20filename%3Dgraalpy-jvm-25.0.1-linux-amd64.tar.gz&response-content-type=application%2Foctet-stream [following]
--2026-01-10 20:03:46-- https://release-assets.githubusercontent.com/github-production-release-asset/129883600/ffa9554c-f1c0-49b5-b6fa-dad10a0f4385?sp=r&sv=2018-11-09&sr=b&spr=https&se=2026-01-11T01%3A50%3A20Z&rscd=attachment%3B+filename%3Dgraalpy-jvm-25.0.1-linux-amd64.tar.gz&rsct=application%2Foctet-stream&skoid=96c2d410-5711-43a1-aedd-ab1947aa7ab0&sktid=398a6654-997b-47e9-b12b-9515b896b4de&skt=2026-01-11T00%3A50%3A17Z&ske=2026-01-11T01%3A50%3A20Z&sks=b&skv=2018-11-09&sig=V5AdaVgBRMpLE6nzkqW74VmlYXVg6A4iWlH1XvL1NVI%3D&jwt=eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmVsZWFzZS1hc3NldHMuZ2l0aHVidXNlcmNvbnRlbnQuY29tIiwia2V5Ijoia2V5MSIsImV4cCI6MTc2ODA5NzAyNiwibmJmIjoxNzY4MDkzNDI2LCJwYXRoIjoicmVsZWFzZWFzc2V0cHJvZHVjdGlvbi5ibG9iLmNvcmUud2luZG93cy5uZXQifQ.KjSG0gtg1SQuvoVffian3snWg2orV-Tbx1kqNiNRZKg&response-content-disposition=attachment%3B%20filename%3Dgraalpy-jvm-25.0.1-linux-amd64.tar.gz&response-content-type=application%2Foctet-stream
Resolving release-assets.githubusercontent.com (release-assets.githubusercontent.com)... 185.199.111.133, 185.199.110.133, 185.199.108.133, ...
Connecting to release-assets.githubusercontent.com (release-assets.githubusercontent.com)|185.199.111.133|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 160187090 (153M) [application/octet-stream]
Saving to: ‘graalpy-jvm-25.0.1-linux-amd64.tar.gz’

graalpy-jvm-25.0.1-linux-amd64.tar.gz 100%[========================================================================>] 152.77M 42.5MB/s in 3.8s

2026-01-10 20:03:50 (40.2 MB/s) - ‘graalpy-jvm-25.0.1-linux-amd64.tar.gz’ saved [160187090/160187090]

(.pytorch-venv) actions@mark1nuc:/surfworks/graalpyjvmtest$ tar xzf graalpy-jvm-25.0.1-linux-amd64.tar.gz
(.pytorch-venv) actions@mark1nuc:/surfworks/graalpyjvmtest$ ls
graalpy-jvm-25.0.1-linux-amd64 graalpy-jvm-25.0.1-linux-amd64.tar.gz
(.pytorch-venv) actions@mark1nuc:/surfworks/graalpyjvmtest$ ./graalpy-jvm-25.0.1-linux-amd64/bin/graalpy -c "
import sys
sys.path.insert(0, '.pytorch-venv/lib/python3.12/site-packages')
import torch._C
print('OK!')
"
File "", line 2
import sys
^
IndentationError: unexpected indent
(.pytorch-venv) actions@mark1nuc:/surfworks/graalpyjvmtest$ ./graalpy-jvm-25.0.1-linux-amd64/bin/graalpy -c "import sys; sys.path.insert(0,'/home/actions/surfworks/warpforge/snakegrinder-dist/.pytorch-venv/lib/python3.12/site-packages'); import torch._C; print('OK')"

A fatal error has been detected by the Java Runtime Environment:

SIGSEGV (0xb) at pc=0x00007a8fca7e984a, pid=105204, tid=105204

JRE version: Java(TM) SE Runtime Environment Oracle GraalVM 25.0.1+8.1 (25.0.1+8) (build 25.0.1+8-LTS-jvmci-b01)

Java VM: Java HotSpot(TM) 64-Bit Server VM Oracle GraalVM 25.0.1+8.1 (25.0.1+8-LTS-jvmci-b01, mixed mode, sharing, tiered, jvmci, jvmci compiler, compressed oops, compressed class ptrs, g1 gc, linux-amd64)

Problematic frame:

C [libtorch_python.so+0x9e984a] pybind11::staticmethod::staticmethod(pybind11::object&&)+0x1a

Core dump will be written. Default location: /tmp/core.105204

An error report file with more information is saved as:

/home/actions/surfworks/graalpyjvmtest/hs_err_pid105204.log

[8.463s][warning][os] Loading hsdis library failed

If you would like to submit a bug report, please visit:

https://bugreport.java.com/bugreport/crash.jsp

The crash happened outside the Java Virtual Machine in native code.

See problematic frame for where to report the bug.

Aborted (core dumped)
(.pytorch-venv) actions@mark1nuc:~/surfworks/graalpyjvmtest$

[morrismeyer]

So this fails on GraalPy JVM mode as well - see the comment above. Here is an updated bug report for that.

Title: Segfault in pybind11::staticmethod during PyTorch import on Linux

Environment:

• GraalPy 25.0.1 (both JVM and Native builds)
• Linux x86_64 (Ubuntu)
• PyTorch 2.7.0 built with GraalPy patches
• Same build works on macOS aarch64

Crash location:
libtorch_python.so pybind11::staticmethod::staticmethod(pybind11::object&&)+0x1a

Reproducer:
graalpy -m venv venv && source venv/bin/activate
pip install torch==2.7.0
python -c "import torch._C" # SIGSEGV

Notes:

• Native libs load fine via ctypes.CDLL()
• Crashes during pybind11 module initialization
• Affects both JVM and native-image modes
• Works on macOS, crashes on Linux

[morrismeyer]

hs_err_pid105204.log

[morrismeyer]

root@mark1nuc:~# lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 22.04.5 LTS
Release: 22.04
Codename: jammy

root@mark1nuc:# ldd --version
ldd (Ubuntu GLIBC 2.35-0ubuntu3.11) 2.35
Copyright (C) 2022 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Written by Roland McGrath and Ulrich Drepper.
root@mark1nuc:#

root@mark1nuc:~# cat /proc/cpuinfo | grep "model name" | head -1
model name : 12th Gen Intel(R) Core(TM) i5-1240P

[morrismeyer]

Update: Minimal pybind11 staticmethod works

I tested a minimal pybind11 module with staticmethod on the same GraalPy Linux setup:

#include <pybind11/pybind11.h>
namespace py = pybind11;
int add(int a, int b) { return a + b; }
PYBIND11_MODULE(test_static, m) {
m.def("add", &add);
m.attr("add") = py::staticmethod(m.attr("add"));
}

$ python -c "import test_static; print(test_static.add(1,2))"
3

This works, so the issue isn't a general pybind11::staticmethod problem. The crash is triggered by something specific
in PyTorch's module initialization.

Possible causes:

• PyTorch's _C module is massive with thousands of bindings - could be a scale/memory issue
• Specific pybind11 patterns unique to PyTorch (e.g., nested classes, custom type casters)
• Interaction between multiple .so files during init (libtorch_cpu.so, libc10.so, etc.)

The crash location pybind11::staticmethod::staticmethod(pybind11::object&&)+0x1a suggests the pybind11::object&&
argument may be invalid when PyTorch calls it, but valid in simpler modules.

[morrismeyer]

Update: Tested GraalPy master (post-December 2025 fixes)

I built GraalPy from the current master branch to test if recent fixes (particularly commit 4b77b68 "Fix: unaligned
pointer caused crashes" from Dec 5, 2025) would resolve this issue.

Build environment:

• GraalPy master (930784d)
• Labs JDK 25.1+8 (for native-image build)
• Same PyTorch 2.7.0 venv as before

Results:

1. JVM mode (mx build): Same crash occurs

A fatal error has been detected by the Java Runtime Environment:

SIGSEGV (0xb) at pc=0x00007f865d9a86ba

C [_C.graalpy250-312-native-x86_64-linux.so+0x65646ba]

pybind11::staticmethod::staticmethod(pybind11::object&&)+0x1a
2. Native-image mode (mx python-svm): SIGSEGV still occurs, but handled more gracefully. Process exits with code 99
instead of crashing with a dump.

2. strace output confirms the segfault:
   123977 --- SIGSEGV {si_signo=SIGSEGV, si_code=SI_KERNEL, si_addr=NULL} ---
   123977 --- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_MAPERR, si_addr=0x7ffe1da09e30} ---
   123977 --- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_MAPERR, si_addr=0x7ffe1da09920} ---
   123977 exit_group(99)

Conclusion: The December "unaligned pointer" fix did not resolve this issue. The crash still occurs in the same location (pybind11::staticmethod::staticmethod) during PyTorch's _C module initialization. The issue is Linux-specific — the same PyTorch build works correctly on macOS.

[morrismeyer]

Root Cause Analysis: GraalPy Tagged Handles Leaked to Native Code

We've identified the root cause of this crash through extensive debugging with gdb.

Summary

GraalPy is passing internal tagged handles (with 0x8000... prefix) to native pybind11 code that expects standard
CPython PyObject* pointers. When pybind11 attempts to dereference these handles to access ob_type at offset 8, it
causes SIGSEGV because the tagged address is not mapped memory.

Detailed Analysis

Crash Location

0x00007fef9a7e984a in pybind11::staticmethod::staticmethod(pybind11::object&&)

Disassembly at Crash Point

mov (%rsi),%rdi # Load PyObject* from pybind11::object into rdi
test %rdi,%rdi # Check if NULL
je ... # Skip if NULL
mov ...,(%rip),%rax # Load PyStaticMethod_Type pointer
=> cmp %rax,0x8(%rdi) # CRASH: Access obj->ob_type (offset 8)

pybind11 is performing a standard CPython type check: obj->ob_type == PyStaticMethod_Type

Register State at Crash

rdi = 0x8000555558605c70 ← GraalPy tagged handle, NOT a valid PyObject*

Memory Access Attempt

(gdb) x/10gx $rdi
0x8000555558605c70: Cannot access memory at address 0x8000555558605c70

The 0x8000... prefix indicates this is a GraalPy internal handle/tag. Standard x86-64 user-space pointers are in the
0x0000... to 0x7fff... range. GraalPy uses tagged pointers internally, but these should never be exposed to native
extensions expecting CPython ABI compatibility.

Call Stack Context

#0 pybind11::staticmethod::staticmethod(pybind11::object&&)
#1 pybind11::class_torch::jit::Graph::def_static<...>
#2 torch::jit::initPythonIRBindings(_object*)
#3 torch::jit::initJITBindings(_object*)
#4 initModule()
#5 PyInit__C()

The crash occurs during PyTorch JIT module initialization when registering static methods on torch::jit::Graph.

Expected CPython PyObject Layout

struct PyObject {
Py_ssize_t ob_refcnt; // offset 0 (8 bytes)
PyTypeObject *ob_type; // offset 8 (8 bytes) ← pybind11 accesses this
}

pybind11 (and all native CPython extensions) expect PyObject* to point to real memory with this layout. GraalPy's
handle 0x8000555558605c70 is not valid memory.

Why macOS Works

This crash is Linux-specific. The same PyTorch build works on macOS. Possible reasons:

1. GraalPy uses a different handle tagging scheme on macOS that keeps addresses in valid memory ranges
2. Platform-specific code paths in GraalPy's native interface layer
3. Different memory layout or handle-to-pointer translation on Darwin vs Linux

Reproduction

Minimal test case on Linux x86-64:
import sys
sys.path.insert(0, '/path/to/pytorch/site-packages')
from torch import _C # SIGSEGV

Conclusion

The bug is in GraalPy's CPython emulation layer. When native code (pybind11/PyTorch) obtains a PyObject* through the C
API, GraalPy is returning its internal tagged handles instead of pointers to properly laid-out PyObject structures.
This needs to be fixed in GraalPy's native interface translation layer, specifically for the Linux platform.

---

Does this look good to post?

❯ yes post it

⏺ I can't post directly to GitHub - you'll need to copy and paste it to the bug report yourself at
#589

This is a solid technical analysis that should help the GraalPy team pinpoint the fix. The key insight is:

1. What: Tagged handles (0x8000...) leaked to native code
2. Where: CPython emulation layer returning handles instead of PyObject*
3. Why Linux only: Different handle tagging scheme or platform-specific code path
4. Impact: Any pybind11 extension accessing ob_type will crash

[morrismeyer]

We re-ran the PyTorch build today using the standard approach:

• GraalPy 25.0.1 native-image (linux-amd64)
• PyTorch 2.7.0 with GraalPy patches applied
• pip install . from patched source

The build crashes with the exact same segfault identified in this issue:

Segfault detected, aborting process.

Stack trace shows the crash in CApiContext.loadCExtModule → FFI call → native pybind11 code - the same tagged handle leak issue where GraalPy passes 0x8000... handles to native code expecting valid PyObject* pointers.

This is a blocking bug for PyTorch on GraalPy Linux. The build setup is not the issue - the root cause analysis in this thread correctly identified a bug in GraalPy's CPython emulation layer on Linux.

Could the GraalPy team provide guidance on:

1. Is there a fix in progress for this tagged pointer issue on Linux?
2. Is there a workaround we can use in the meantime?
3. What GraalPy version might include a fix?

[msimacek]

Hi @morrismeyer, the problem is most likely that patch we ship for torch didn't apply correctly in your environment. Do you have the patch tool installed? If yes, could you please re-run the build in verbose mode and post the pip install torch --no-binary torch --no-cache -v? You should see something like:

WARNING: Disabling truststore because platform isn't supported
Looking in indexes: https://pypi.org/simple, https://www.graalvm.org/python/wheels/
Collecting torch
  Downloading https://github.com/pytorch/pytorch/releases/download/v2.7.0/pytorch-v2.7.0.tar.gz (286.0 MB)
     ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 286.0/286.0 MB 7.9 MB/s eta 0:00:00
auto-patching C API usages in /tmp/pip-install-12pd19o7/torch_4f434fd6cd4f40e5ba80f18c7c89966c/third_party/tensorpipe/third_party/pybind11/include/pybind11/cast.h
auto-patching C API usages in /tmp/pip-install-12pd19o7/torch_4f434fd6cd4f40e5ba80f18c7c89966c/third_party/tensorpipe/third_party/pybind11/include/pybind11/pybind11.h
auto-patching C API usages in /tmp/pip-install-12pd19o7/torch_4f434fd6cd4f40e5ba80f18c7c89966c/third_party/onnx/third_party/pybind11/include/pybind11/pytypes.h
auto-patching C API usages in /tmp/pip-install-12pd19o7/torch_4f434fd6cd4f40e5ba80f18c7c89966c/third_party/onnx/third_party/pybind11/include/pybind11/cast.h
auto-patching C API usages in /tmp/pip-install-12pd19o7/torch_4f434fd6cd4f40e5ba80f18c7c89966c/third_party/onnx/third_party/pybind11/include/pybind11/pybind11.h
auto-patching C API usages in /tmp/pip-install-12pd19o7/torch_4f434fd6cd4f40e5ba80f18c7c89966c/third_party/protobuf/python/google/protobuf/pyext/message_factory.cc
auto-patching C API usages in /tmp/pip-install-12pd19o7/torch_4f434fd6cd4f40e5ba80f18c7c89966c/third_party/protobuf/python/google/protobuf/pyext/descriptor.cc
auto-patching C API usages in /tmp/pip-install-12pd19o7/torch_4f434fd6cd4f40e5ba80f18c7c89966c/third_party/protobuf/python/google/protobuf/pyext/message.cc
auto-patching C API usages in /tmp/pip-install-12pd19o7/torch_4f434fd6cd4f40e5ba80f18c7c89966c/third_party/protobuf/python/google/protobuf/pyext/repeated_composite_container.cc
auto-patching C API usages in /tmp/pip-install-12pd19o7/torch_4f434fd6cd4f40e5ba80f18c7c89966c/third_party/pybind11/include/pybind11/pytypes.h
auto-patching C API usages in /tmp/pip-install-12pd19o7/torch_4f434fd6cd4f40e5ba80f18c7c89966c/third_party/pybind11/include/pybind11/cast.h
auto-patching C API usages in /tmp/pip-install-12pd19o7/torch_4f434fd6cd4f40e5ba80f18c7c89966c/third_party/pybind11/include/pybind11/pybind11.h
auto-patching C API usages in /tmp/pip-install-12pd19o7/torch_4f434fd6cd4f40e5ba80f18c7c89966c/functorch/csrc/dim/dim.cpp
auto-patching C API usages in /tmp/pip-install-12pd19o7/torch_4f434fd6cd4f40e5ba80f18c7c89966c/torch/csrc/Storage.cpp
auto-patching C API usages in /tmp/pip-install-12pd19o7/torch_4f434fd6cd4f40e5ba80f18c7c89966c/torch/csrc/Module.cpp
auto-patching C API usages in /tmp/pip-install-12pd19o7/torch_4f434fd6cd4f40e5ba80f18c7c89966c/torch/csrc/distributed/c10d/init.cpp
auto-patching C API usages in /tmp/pip-install-12pd19o7/torch_4f434fd6cd4f40e5ba80f18c7c89966c/torch/csrc/autograd/python_variable.cpp
auto-patching C API usages in /tmp/pip-install-12pd19o7/torch_4f434fd6cd4f40e5ba80f18c7c89966c/torch/csrc/autograd/profiler_python.cpp
auto-patching C API usages in /tmp/pip-install-12pd19o7/torch_4f434fd6cd4f40e5ba80f18c7c89966c/torch/csrc/utils/pythoncapi_compat.h
  Looking for GraalPy patches for torch
  Patching package torch using torch-2.7.0.patch
patching file c10/cuda/CUDACachingAllocator.cpp
patching file c10/cuda/CUDACachingAllocator.h
patching file functorch/csrc/dim/dim.cpp
patching file pyproject.toml
patching file test/test_overrides.py
patching file test/test_python_dispatch.py
patching file third_party/fbgemm/CMakeLists.txt
patching file third_party/pybind11/include/pybind11/detail/common.h
patching file third_party/pybind11/include/pybind11/detail/internals.h
patching file third_party/pybind11/include/pybind11/detail/type_caster_base.h
patching file third_party/pybind11/include/pybind11/eval.h
patching file third_party/pybind11/include/pybind11/pybind11.h
patching file third_party/pybind11/include/pybind11/pytypes.h
patching file tools/build_pytorch_libs.py
patching file tools/generate_torch_version.py
patching file torch/_dynamo/decorators.py
patching file torch/_tensor_str.py
patching file torch/csrc/Generator.cpp
patching file torch/csrc/Module.cpp
patching file torch/csrc/autograd/python_variable_indexing.cpp
patching file torch/csrc/autograd/python_variable_indexing.h
patching file torch/csrc/cuda/Module.cpp
patching file torch/csrc/dynamo/cpython_defs.c
patching file torch/csrc/dynamo/eval_frame.c
patching file torch/csrc/dynamo/eval_frame_cpp.cpp
patching file torch/csrc/dynamo/extra_state.cpp
patching file torch/csrc/dynamo/framelocals_mapping.cpp
patching file torch/csrc/dynamo/guards.cpp
patching file torch/csrc/jit/python/python_tracer.cpp
patching file torch/csrc/profiler/python/combined_traceback.cpp
  Running command pip subprocess to install build dependencies
  Using pip 24.3.1 from /home/msimacek/git/graalpython/venv/lib/python3.12/site-packages/pip (python 3.12)
  WARNING: Disabling truststore because platform isn't supported

You don't have to run the whole build again, it's enough to let it get to the patch stage and then you can ctrl+c out of it and post the output.

GraalPy uses tagged pointers internally, but these should never be exposed to native
extensions expecting CPython ABI compatibility.

GraalPy doesn't promise the same ABI as CPython, only API. Exposing tagged pointers is intended. Libraries shouldn't normally dereference them. Pybind11 doesn't do that in the current versions, the current upstream version supports GraalPy as it is, with tagged pointers everywhere. The version in torch 2.7 is older, so we patch it (torch is slow-ish in adopting pybind11 versions and we're slow in adopting torch versions). We test torch 2.7 on Linux regularly without this kind of problems, so I strongly suspect the problem is with the patching.

[morrismeyer]

Attached is the log from running the above pip install command verbosely.

torch-verbose.log

[msimacek]

Hmm, looks like patching worked fine. I just tried rebuilding torch locally on 25.0.1 on Linux and it imports fine. You narrowed down the invalid access to an ob_type read of a staticmethod object, but exactly that is removed by the patching. This is the relevant change that autopatch does:

diff --git a/third_party/onnx/third_party/pybind11/include/pybind11/pytypes.h b/third_party/onnx/third_party/pybind11/include/pybind11/pytypes.h
index d5f6af8e0..d777f31df 100644
--- a/third_party/onnx/third_party/pybind11/include/pybind11/pytypes.h
+++ b/third_party/onnx/third_party/pybind11/include/pybind11/pytypes.h
@@ -1329,7 +1329,7 @@ inline bool PyUnicode_Check_Permissive(PyObject *o) {
 #    define PYBIND11_STR_CHECK_FUN PyUnicode_Check
 #endif
 
-inline bool PyStaticMethod_Check(PyObject *o) { return o->ob_type == &PyStaticMethod_Type; }
+inline bool PyStaticMethod_Check(PyObject *o) { return Py_TYPE(o) == &PyStaticMethod_Type; }
 
 class kwargs_proxy : public handle {
 public:

There are no ob_type accesses after the patching left in the code. Is it possible that pip is picking up a cached wheel from some past build when the patch didn't apply or was done with an older version of GraalPy? Could you please run (in the graalpy virtualenv) pip cache remove torch and reinstall torch again with pip install -v torch --force-reinstall?