Files
RustPython/Lib/test
Jeong, YunWon 259ce8ce66 Fix the itertools.tee leak and race, the contextvars and generator races, _asyncio's InvalidStateError lookup, and _imp's frozen data (#8518)
* _imp: read get_frozen_object's data as a whole marshal value

The data argument went through deserialize_code(), which reads a code body
without the type byte in front of it, so nothing marshal.dumps() produces was
accepted. Read it with marshal.loads() and require a code object back.

Assisted-by: Claude

* _imp: bind find_frozen's arguments with FromArgs

The arity check was done by hand on a FuncArgs. Take the arguments through a
FromArgs struct instead, which makes withdata keyword-only, and fill in the
data it asks for: the frozen encoding is not marshal, so the code is
re-serialized into what get_frozen_object() reads back.

Assisted-by: Claude

* itertools: give tee's shared buffer a Python type

The buffer was a PyRc<PyItertoolsTeeData>, which is not a Python object, so the
collector could not walk into it and any cycle running through a tee was
uncollectable. Make it the _tee_dataobject type with a traverse, held by
PyRef, and split the rest along the same lines: tee() is a function, _tee is
the iterator type it builds, and _tee takes a single iterable rather than
returning a tuple from __new__. _tee is weak-referenceable, tee() rejects a
negative n with ValueError and reserves its tuple fallibly.

test_itertools.test_tee passes now; its expectedFailure marker is removed.

Assisted-by: Claude

* contextvars: hold the shared context state under locks

The variable map was a RefCell, the enter flag, the context index, the token's
used flag and the variable hash were Cells, and each carried an unsafe impl
Sync. A Context or ContextVar shared between threads overlapped their borrows
and panicked. The map and the per-variable cache are now PyMutex, the flags and
the index are atomics, entering a context is a compare_exchange, and the three
unsafe impl Sync are gone.

The cache also stopped being read through AtomicCell::as_ptr, which raced a
concurrent store on a value holding a PyObjectRef.

Values displaced from the map or the cache are dropped after the lock is
released: __del__ can come straight back into the same context, and the locks
are not reentrant.

Assisted-by: Claude

* generator: read the frame state under the running claim

send(), send_none(), throw() and close() read `closed` and `frame.lasti()`
before `running` was compare_exchanged, so the frame they went on to resume
could be one another thread had already advanced. A resume that decided from
`lasti() == 0` that the generator had not started pushes no value onto the
value stack, and the code after the yield pops one, which underflows the stack.

The compare_exchange now hands back a guard, taken before those reads and
released after maybe_close(), so the generator is retired while it is still
claimed.

Assisted-by: Claude

* itertools: claim a tee's position and its buffer as one step

`_tee::next` read `index` and moved it on afterwards, and
`_tee_dataobject::get_item` released `running` before the value it fetched
from the source was cached.

Two callers on one `_tee` then read the same index, hand out the same value
twice and advance past a value that was never cached, which leaves `index`
past `values.len()` and indexes the buffer out of bounds. Two callers at the
same index on separate tees each fetch a value from the source, and one of the
two is dropped without reaching a caller.

Both claims now cover the read and the update.

Assisted-by: Claude

* _asyncio: require InvalidStateError to be a type

new_invalid_state_error() called whatever `asyncio.exceptions.InvalidStateError`
names and unwrapped the downcast of the result, so a future asked for a result
it does not have panicked once that attribute was rebound to something that is
not an exception:

    asyncio.InvalidStateError = lambda *args: 42
    _asyncio.Future(loop=object()).result()

The type is looked up the way get_cancelled_error_type() looks its own up, and
raised with new_exception_msg; a lookup that does not produce an exception type
falls back to RuntimeError, as the other arms already did.

Assisted-by: Claude
2026-08-14 16:05:30 +09:00
..
2026-03-01 11:36:46 +09:00
2025-08-24 10:36:07 +03:00
2023-04-20 15:36:28 +09:00
2023-03-02 15:01:12 +09:00
2026-05-24 19:56:35 +09:00
2026-02-05 00:21:34 +09:00
2022-10-18 03:26:29 +09:00
2026-05-12 20:51:33 +09:00
2023-03-01 18:06:50 +09:00
2026-03-01 11:36:46 +09:00
2026-02-02 02:02:12 +09:00
2026-02-13 22:15:52 +09:00
2026-01-25 15:20:05 +09:00
2026-05-24 19:56:35 +09:00
2026-08-03 17:52:42 +09:00
2026-02-13 13:36:33 +02:00
2026-02-13 13:36:33 +02:00
2026-02-13 14:13:30 +09:00
2024-06-24 19:00:54 +09:00
2026-02-11 16:50:23 +09:00
2026-02-08 20:36:35 +09:00
2026-02-10 00:48:22 +09:00
fix
2026-02-12 01:01:35 +09:00
2026-02-13 13:36:33 +02:00
2026-05-30 20:16:10 +09:00
2026-02-03 22:10:31 +09:00
2026-02-06 00:15:18 +09:00
2026-06-10 11:14:05 +09:00
2026-05-17 19:49:19 +09:00
2026-06-15 11:21:28 +09:00
2026-03-06 06:00:08 +09:00
2026-02-13 13:55:05 +09:00
2026-02-14 18:19:57 +02:00
2026-01-25 00:18:55 +09:00
2026-01-26 10:40:22 +09:00
2026-07-07 09:19:25 +09:00
2026-02-03 22:10:31 +09:00
2026-03-12 18:08:56 +09:00
2025-08-31 11:58:21 +03:00
2026-02-06 01:14:55 +09:00
2026-02-13 13:36:33 +02:00
2026-02-04 18:32:45 +09:00
2026-03-03 19:57:50 +09:00
2026-02-28 22:50:51 +09:00
2025-04-21 21:11:42 -07:00
2026-01-31 20:51:53 -05:00
2025-12-12 10:37:40 +09:00
2026-06-15 11:12:39 +09:00
2026-02-14 21:40:04 +09:00
2026-02-14 09:18:09 +09:00
2025-03-26 23:12:21 -05:00
2026-03-21 22:49:09 +09:00
2026-06-11 12:15:21 +09:00
2026-03-03 21:58:46 +09:00
2025-01-17 18:04:25 -08:00
2026-01-25 00:18:55 +09:00
2026-01-25 00:18:55 +09:00
2026-02-13 13:44:28 +09:00
2026-01-25 00:18:55 +09:00
2026-02-13 13:42:22 +09:00
2026-01-25 00:18:55 +09:00
2026-06-15 11:19:40 +09:00
2026-03-05 17:25:59 +09:00
2023-04-20 15:36:28 +09:00