Binder: closing a PyObject argument inside an upcall crashes later (SIGSEGV in Py_XDECREF on the Cleaner thread) #98

What

A KSP-bound Kotlin function receives a Python object as PyObject? and calls close() on it inside the call. The JVM later dies with SIGSEGV in Py_XDECREF on the Cleaner-0 thread, during PyObjectKt.topLevelDecRefAction → CleanupAction.run. In other words, one reference is released twice.

fun tpTouch(token: PyObject?): Long { token?.close(); return 1L }

UpcallTrampoline.kt:71 documents arguments as borrowed, with the wrapper built borrowed = true so that it takes its own reference. On that basis close() should hand back exactly the reference the wrapper took.

Evidence (ksp-fixtures/app, TypedPython #45 test, desktop, 3.14.7 GIL)

• With close(): Gradle Test Executor exits 134. hs_err: SIGSEGV at libpython3.14.dylib Py_XDECREF; the Java frames are topLevelDecRefAction ← PyObject$1.invoke ← CleanupAction.run ← PhantomCleanableRef.performCleanup (Cleaner-0).
• Without close(): no crash. After 10,000 calls the token's sys.getrefcount has gone from 10 to 17,350 until the Kotlin collector runs. Release is deferred, as designed.

Where to look

PyAutoCloseable.close() → PlatformCleaner.close(): Java's Cleanable.clean() is idempotent, so close() plus a later Cleaner run should not release twice by itself. The second release must come from somewhere else. Candidates:

• the trampoline or argument conversion also dropping the wrapper's reference;
• a wrapper built borrowed = false on this path;
• two wrappers over one pointer.

AGENTS §16's reference-convention warning describes exactly this failure.

Done when

A ksp-fixtures test that closes a PyObject argument inside an upcall, 10,000 times, runs clean and leaves the refcount unchanged once the Kotlin collector has run. Nothing is released twice.