Skip to content

Conversation

@fatelei
Copy link
Contributor

@fatelei fatelei commented Dec 18, 2025

the original code precomputed nblocks at the beginning of the function, but when a reentrant
writer cleared the array during the first callback, self->ob_item became NULL. The loop continued iterating based on the cached values and dereferenced the null pointer.

ivonastojanovic and others added 27 commits December 18, 2025 11:43
The bytecode panel appears when a user generates a heatmap with
--opcodes and clicks the button to unfold a line and display the
bytecode instructions. Currently, an empty space appears on the
left where the line number, self, and total columns are displayed.
This area should instead extend those columns, rather than leaving
a gap.
…sion` in `xml.sax.expatreader` & `xml.sax.handler` (python#142898)
* Invalidating an executor does not cause arbitrary code to run
* Executors are only freed at safe points
Now that we specialize range iteration in the interpreter for the common
case where the iterator has only one reference, there's not a
significant performance cost to making the iteration thread-safe.
Co-authored-by: Stan Ulbrych <89152624+StanFromIreland@users.noreply.github.com>
…f an integer input (python#142483)

If *a* is an integer, the sign of *a* is discarded in the C source code. Clarify this behavior to prevent foot guns, where a common use case might naively assume that flipping the sign will produce different sequences (e.g. for a train/test split of a synthetic data generator in machine learning).

Co-authored-by: Adam Turner <9087854+AA-Turner@users.noreply.github.com>
…e tutorial (pythonGH-142314)

Co-authored-by: Stan Ulbrych <89152624+StanFromIreland@users.noreply.github.com>
Co-authored-by: Éric <merwok@netwok.org>
Co-authored-by: Daniele Nicolodi <daniele@grinta.net>
Co-authored-by: Peter Bierma <zintensitydev@gmail.com>
…ythongh-142599)

This makes generator frame state transitions atomic in the free
threading build, which avoids segfaults when trying to execute
a generator from multiple threads concurrently.

There are still a few operations that aren't thread-safe and may crash
if performed concurrently on the same generator/coroutine:

 * Accessing gi_yieldfrom/cr_await/ag_await
 * Accessing gi_frame/cr_frame/ag_frame
 * Async generator operations
…142995)

TSan treats compare-exchanges that fail as if they are writes
so there is a false positive with the read of gi_frame_state in
gen_close.
…-142957)

The use of memmove and _Py_memory_repeat were not thread-safe in the
free threading build in some cases. In theory, memmove and
_Py_memory_repeat can copy byte-by-byte instead of pointer-by-pointer,
so concurrent readers could see uninitialized data or tearing.

Additionally, we should be using "release" (or stronger) ordering to be
compliant with the C11 memory model when copying objects within a list.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.