[Bug]: GC hangs for a slotted Python subclass of a native weak-reference type
Nobody has claimed this yet.
Assessment
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Newbie friendliness
- 45/100
Research direction
Start by running reproduce_runtime_gc.py with gc_probe.c using the documented graalpy command and confirm the differing Python and native weak-reference offsets and the collection timeout. Trace the reported layout and cyclic-GC handling for subclassable native weak-reference types; done means the offsets agree and gc.collect() reclaims the self-cycle within the timeout.
Written by the indexing model from the issue text.
Description
Describe the bug
A Python subclass with a nonempty __slots__ tuple can expose one weak-reference offset through its Python type while its native type representation exposes a different offset. If an ordinary native object field occupies the native offset, cyclic garbage collection can treat that field as the weak-reference list and fail to complete.
The standalone reproducer uses only the Python C API. It defines a heap type with an ordinary integer field before a Python reference field and weak-reference field, then creates a Python subclass with __slots__ = ("extra",). The subclass reports:
Python layout: 48 32
Native layout: (48, 24)
After assigning the ordinary Python reference field to the instance itself, gc.collect() does not return within 15 seconds.
This can affect extension classes that support both subclassing and weak references. An unreachable cycle can hang collection rather than being reclaimed.
Operating system
Linux
CPU architecture
x86_64
GraalPy version
25.3.4.1, Python 3.13.14, sys.implementation.version == 25.3.4, source revision 6bd9d25023bf713ae3dd7e83ee620c897a2c51d0
JDK version
25.0.4.1
Context configuration
No response
Steps to reproduce
Place the attached gc_probe.c and reproduce_runtime_gc.py in one directory, then run:
graalpy reproduce_runtime_gc.py graal-subclass
The script compiles the extension using the selected interpreter's headers and runs collection in a subprocess with a 15-second timeout.
Observed output:
3.13.14 (Wed Aug 19 15:15:54 UTC 2026)
[Graal, GraalVM CE, Java 25.0.4.1 (amd64)]
Python layout: 48 32
Native layout: (48, 24)
collecting
Collection did not return within 15 seconds.
The command exits with status 124.
Expected behavior
The Python-visible and native weak-reference offsets should describe the same object layout, and collection should return after reclaiming the unreachable self-cycle.
Stack trace
Additional context
No response
- Dominant language
- Python
- Stars
- 1.6k
- Forks
- 155
- Avg merge
- 9h 42m
- Merged PRs (30d)
- 36
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from oracle/graalpython
-
bug
Difficulty 2/5 1-3 hours Newbie friendliness 74/100
oracle/graalpython#1105 ·
-
bug
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
oracle/graalpython#1102 ·
-
bug
Difficulty 3/5 1-2 days Newbie friendliness 74/100
oracle/graalpython#1133 ·
-
bug
Difficulty 3/5 1-2 days Newbie friendliness 68/100
oracle/graalpython#1112 ·
-
bug
Difficulty 3/5 1-2 days Newbie friendliness 68/100
oracle/graalpython#1111 ·
All issues in oracle/graalpython
Similar issues
-
Difficulty 1/5 Under an hour Newbie friendliness 90/100
-
bug
Difficulty 2/5 1-3 hours Newbie friendliness 86/100
zostera/django-bootstrap4#894 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
use-agent-os/agent-os#3276 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 88/100
zephyrproject-rtos/zephyr#119726 ·
-
area/auth bug comp/agent P3 platform/discord type/security
Difficulty 2/5 1-3 hours Newbie friendliness 88/100
NousResearch/hermes-agent#117848 ·