Fix crashes found hunting the last open fuzzing record - #8524

Follow-up to #8514 and #8518. Those closed every record in the fuzzing + static-review catalogs except one: RUSTPY-0007 face 7c, the object-core segfault reported in the selectors and asyncio_queues vehicles, which has no reproducer and whose crash dirs are not public. Hunting it turned up crashes that were not in the catalog at all, and hunting those turned up more. Every one is reachable from ordinary pure Python, and CPython 3.14 answers all of them with a normal exception or a result.

One commit per defect.

The slot-offset specialization did not check the descriptor's type

LOAD_ATTR/STORE_ATTR specialize member-descriptor access by caching the descriptor's slot offset and guarding the specialized instruction on the owner's type version. descr_get/descr_set check on every access that the instance belongs to the type the descriptor was defined for; the specializer skipped that check, so a descriptor lifted from a wider class and bound to a narrower one indexed past the instance's slot array once the cache warmed up:

class Big:
    __slots__ = ("a0", "a1", "a2", "a3", "a4", "a5", "a6", "a7")
class Narrow:
    __slots__ = ("z",)

Narrow.x = Big.__dict__["a7"]
o = Narrow()
for _ in range(1000):
    try: o.x            # TypeError until specialized, then a panic
    except TypeError: pass

A class with __slots__ = () reached the ext_ref().unwrap() on the same line instead. Both halves are covered in builtin_type.py, for the load, the store and the delete.

This one is the reason for the hunt: object::core::PyInner as the top frame, in the object core, independent of the already-guarded recursion paths — the signature reported for face 7c. Without the crash dirs that stays a match, not a diagnosis.

socket.recv() reserved its buffer infallibly

recv() and recvfrom() passed the caller's bufsize to Vec::with_capacity, so an unreachable size went through handle_alloc_error and aborted the process before any syscall. try_reserve_exact reports MemoryError.

__call__ and __get__ slot dispatches were not counted as recursion

Both slot wrappers re-enter Python without pushing a frame, so when the special method names the object it was looked up on, nothing bounded the nesting and the native stack ran out:

class C: pass
c = C(); C.__call__ = c
c()                                     # SIGSEGV

class D: pass
d = D(); D.__get__ = d; D.x = d
d.x                                     # SIGSEGV

vm.with_recursion around the two dispatches raises RecursionError, the way Py_EnterRecursiveCall bounds a tp_call dispatch. Measured against a build without the guards, it costs about 5% on a __call__ dispatch and 3% on a __get__ dispatch through these wrappers; both only run for types whose special method is defined in Python.

CPython answers the second one with TypeError: 'D' object is not callable, because slot_tp_descr_get looks __get__ up with a plain _PyType_Lookup and calls it directly, while call_special_method binds it through the descriptor protocol and so goes round again. The crash is gone either way; the remaining difference is which exception comes out, and the snippet accepts both.

with_recursion was charging the wrong budget

Putting a guard on a native dispatch made test_tomllib's two recursion-limit tests fail, and the guard was right to be there — with_recursion was spending the wrong thing. It checked the limit sys.setrecursionlimit() sets and incremented the same counter pushing a frame does, so bounding a native dispatch took frames away from the Python code underneath it, and took them where sys._getframe() cannot see them: test.support.get_recursion_available() counted frames that were no longer available. Py_EnterRecursiveCall bounds the native stack, a separate budget, and the C stack check with_recursion already performs is exactly that bound; the limit check and the counter are gone.

ParamSpecArgs formatted its origin with {:?}

ParamSpecArgs/ParamSpecKwargs fell back to a Rust {:?} of __origin__ when it had no __name__. That walks the object graph natively, through Debug for PyInner, where no recursion guard sits — the same shape as the PyAtomicRef Debug type confusion fixed in #8514, and reachable the same way, through a formatting fallback:

a = object()
for _ in range(30000):
    a = typing.ParamSpecArgs(a)
repr(a)                                 # SIGSEGV

The origin is now shown by its repr, which is guarded, and a ParamSpec origin is recognized by its type rather than by carrying a __name__ — matching paramspecargs_repr.

A lock was held across a call back into Python

Two commits, one class of defect: a lock or a borrow taken and then held while running code that can reach the same object, so a callback that touches it waits on a lock its own caller holds. The process wedges — no exception, no timeout, no way out.

_asyncio.future_add_to_awaited_by(fut, waiter)  # waiter.__hash__ adds again
select.select(elements, [], [], 0)              # fileno() clears `elements`
select.poll().poll(1000)                        # a SIGALRM handler registers

memoryview(b)[0:4] = memoryview(b)[::-1]        # source overlaps destination
BytesIO(b"abcdef").readinto(its own getbuffer())
array("i", [0])[0] = x                          # x.__index__ appends
mmap_obj.write(memoryview(mmap_obj))
bytearray(b"-").join(hostile_iterable)
bytearray(b"%s") % hostile_tuple

Which fix applies depends on how the lock is reached. Where the value is only needed after the call, the call happens first: array.__setitem__ and memoryview.__setitem__ convert the value before taking the write borrow, and array/bytearray answer "is this resizable" before taking the write lock rather than after — an export is exactly a borrow someone else is already holding, so asking under a lock asks too late. Where the source aliases the destination, the source is copied first: mmap.write, BytesIO.readinto and memoryview slice assignment resolve a memoryview argument to the object it views and compare identities. Where an iterable drives the loop, the container is read again on each step rather than borrowed for the duration: bytearray.join, bytearray.__mod__, and select.select's list extraction, which now re-reads the list the way map_iterable_object() does. poll() waits on a copy of its descriptors, and a future's awaited-by set is built outside the future's lock.

A TextIOWrapper cookie is validated in this commit too: it has to name a position inside what was decoded in characters as well as in bytes, and only the byte offset was checked — the character count is what read() and tell() index with, so a forged cookie panicked.

A size taken from Python went into an infallible allocation

Eight places passed a caller-supplied size straight to Vec::with_capacity or equivalent, so the process aborted through handle_alloc_error before any exception could be raised: center(), ljust(), rjust() and zfill() on str/bytes/bytearray; expandtabs(), which builds its runs of spaces from tabsize; Buffered{Reader,Writer,Random}(buffer_size=); read(), read1() and FileIO.read(); bytes(n) and bytearray(n); and pbkdf2_hmac()'s derived key length. Each reports MemoryError now, or OverflowError where the argument does not fit the C type it is declared with (expandtabs, pbkdf2_hmac).

bytes(n) and the read paths allocate with alloc_zeroed rather than reserving and then memsetting, so FileIO.read(2**40) costs the pages that are written to rather than all of them, as PyBytes_FromStringAndSize + calloc does.

marshal answered allow_code by walking the result again

allow_code=False was enforced by traversing the finished value a second time, looking for a code object, with no depth counter and no record of what it had already visited. A value referring back to itself never terminated, and a value nested deeply enough ran off the native stack:

l = []; l.append(l)
marshal.dumps(l, allow_code=False)      # SIGSEGV

w_object() and r_object() answer it where the code object actually is, inside the walk that already bounds its depth and resolves FLAG_REF back-references — which is where CPython answers it. The 12 differential cases (dumps/loads × code in a tuple, list, dict, set, frozenset, nested code) now produce the same exception with the same message.

Two more in the same file: a container length is read the way r_long() reads one — signed, so a length with the top bit set is out of range rather than four billion items to reserve room for — and load() no longer holds a borrow of the buffer read() returned across the seek() it makes afterwards.

A thread's top frame was published as one pointer and read as another

set_current_frame() casts the Py<FrameObject> it publishes straight to *mut FrameObject, so ThreadSlot::top_frame holds the object's base address. sys._current_frames() read it back through Py::from_payload_ptr(), which subtracts the payload offset from what it is given. The reference it took therefore incremented, and later decremented, a word 48 bytes ahead of the frame — inside the object allocated before it. PyInner<FrameObject> is 0xe0 bytes and frames are recycled through a freelist, so two frames adjacent in the size class are the ordinary case, and that word is exactly the neighbour's cold OnceLock state. INCOMPLETE(3) + 1 == 4, and 4 & 0b11 reads as COMPLETE, so initialization was skipped and a value slot that had never been written was read as a Box<FrameColdData> and its mutex locked. The crash lands in the thread that owns the neighbour, not the one that read.

The slot holds *mut Py<FrameObject> now, which is what both sides mean.

test_sys.test_current_frames never reached this: its thread is blocked in Event.wait(), whose topmost frame is a datastack frame with no FrameObject, so top_frame is null there and the reader takes the materialize path instead. The new snippet takes _current_frames() against threads that are running.

stop-the-world could return with a thread still executing bytecode

do_suspend() published SUSPENDED and only then re-read requested, restoring itself to ATTACHED if the stop had ended meanwhile. That made a parked thread the second writer able to leave SUSPENDED, so a stop whose completion check had already observed it parked could be undone behind the requester's back:

worker    CAS ATTACHED -> SUSPENDED
requester all_non_requester_suspended() -> true, world_stopped = true
requester start_the_world(): requested = false, then walks the registry
worker    reads requested == false, stores ATTACHED

With the store landing inside that walk the debug assertion in start_the_world fires. With the walk already past the slot, a following stop force-parks the thread DETACHED -> SUSPENDED, counts it as stopped, and the store then puts it back to ATTACHED — with the world declared stopped and the thread running bytecode. That half is silent.

requested is set in init_thread_countdown() and cleared in start_the_world() with the thread registry held, and start_the_world() keeps holding it while it releases every SUSPENDED thread. Taking the registry around the check and the transition leaves only two orders: park before that release pass and be woken by it, or find the request already withdrawn and stay ATTACHED. The requester is the only writer that takes a thread out of SUSPENDED again, and the self-restore is gone.

The assertion reproduced once in six runs of the new snippet, which drives about 70k stops a second; 30 runs after the change are clean. gc.collect() stress does not reach the rate that exposes it.

atexit identified a callback by an address it had let go of

atexit.unregister() releases the callback list around each __eq__ call, and identified the entry it had compared by the address of its Box. __eq__ can call atexit._clear(), which drops that Box, and atexit.register(), whose new Box lands on the freed allocation; the identity search then matched the freshly registered callback and removed it. Entries are Arc-shared now, so unregister() holds the one it is comparing and matches it with Arc::ptr_eq — an address cannot be reused while the comparison that named it is still running.

Tests

Regression cases go where the feature is tested: builtin_type.py, builtin_memoryview.py, builtin_str.py, builtin_bytes.py, builtin_hash.py, recursion.py, stdlib_socket.py, stdlib_typing.py, stdlib_select.py, stdlib_asyncio.py, stdlib_io.py, stdlib_io_bytesio.py, stdlib_array.py, stdlib_marshal.py, stdlib_hashlib.py, stdlib_types.py, stdlib_atexit.py, stdlib_threading_current_frames.py. The snippet suite runs each of them under host CPython as well, so every case is checked against 3.14 by construction.

The full snippet suite passes (426 tests). Of the CPython suite, test_descr, test_typing, test_socket, test_types, test_dynamic, test_richcmp, test_class, test_property, test_super, test_array, test_mmap, test_bytes, test_memoryview, test_io, test_re, test_buffer, test_memoryio, test_bufio, test_fileio, test_str, test_struct, test_marshal, test_tomllib, test_atexit, test_sys, test_threading, test_thread, test_threading_local, test_gc, test_faulthandler, test_traceback, test_frame pass, as does a wider batch of 43 modules including test_asyncio, test_collections, test_enum, test_dataclasses, test_functools, test_weakref and test_generators. The CI clippy line is clean.

test_support.test_get_recursion_depth started passing once with_recursion stopped charging the frame budget, so its expectedFailure is removed.

Still open

Face 7c itself remains unconfirmed: nothing here can be tied to the reported crash dirs without their backtraces, and the vehicles' surfaces (selectors with hostile fileno(), asyncio queues plus the _asyncio task registry, both from several threads) still produce no crash. Details in #8325.

One thread defect reported alongside these is not addressed: a _thread._local whose __del__ re-registers during teardown is said to abort the process out of the TLS destructor, and three repro shapes did not produce it. What that hunt did turn up is a divergence rather than a crash — a value resurrected by a __del__ during teardown is never finalized, because cleanup_thread_local_data() takes the guard list once and anything re-registered during that drop is left to Rust's TLS destructor with no VM to run it. CPython finalizes it at interpreter shutdown.

🤖 Generated with Claude Code

Summary by CodeRabbit

• Bug Fixes
  • Improved handling of oversized allocations, padding operations, socket reads, and buffer sizes with appropriate Python errors.
  • Strengthened marshal validation, including invalid lengths and code-object permission checks.
  • Fixed overlapping memory, array, BytesIO, and mmap operations.
  • Improved thread, signal, polling, callback, recursion, and descriptor safety.
  • Corrected memoryview casting, slicing, and negative-stride behavior.
• Tests
  • Added regression coverage for memory handling, marshal validation, recursion, threading, I/O, networking, and buffer operations.