[Bug]: GC hangs for a slotted Python subclass of a native weak-reference type

Open
#1,157 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
45/100
Issue type
Bug
Clarity
Mostly clear
Activity status
Active
Tech stack
c, java, python
Domain
backend

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

bug
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.

gc_probe.c

reproduce_runtime_gc.py

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

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from oracle/graalpython

All issues in oracle/graalpython

Similar issues

More Python issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.