* Count number of actually tracked objects, instead of trackable objects. This ensures that untracking tuples has the desired effect of reducing GC overhead
* Do not track most untrackable tuples during creation. This prevents large numbers of small tuples causing execessive GCs.
* [3.14] gh-140067: Fix memory leak in sub-interpreter creation (GH-140111)
Fix memory leak in sub-interpreter creation caused by overwriting of the previously used `_malloced` field. Now the pointer is stored in the first word of the memory block to avoid it being overwritten accidentally.
(cherry picked from commit 59547a251f)
Co-authored-by: Shamil <ashm.tech@proton.me>
Co-authored-by: Kumar Aditya <kumaraditya@python.org>
gh-140257: fix data race on eval_breaker during finalization (GH-140265)
(cherry picked from commit c8729c9909)
Co-authored-by: Shamil <ashm.tech@proton.me>
The previous `Py_REFCNT(x) == 1` checks can have data races in the free
threaded build. `_PyObject_IsUniquelyReferenced(x)` is a more conservative
check that is safe in the free threaded build and is identical to
`Py_REFCNT(x) == 1` in the default GIL-enabled build.
(cherry picked from commit 32c264982e)
Co-authored-by: Sergey Miryanov <sergey.miryanov@gmail.com>
Revert GH-131993.
Fix swallowing some syntax warnings in different modules if they accidentally
have the same message and are emitted from the same line.
Fix duplicated warnings in the "finally" block.
(cherry picked from commit 279db6bede)
Co-authored-by: Serhiy Storchaka <storchaka@gmail.com>
* Update 2025-10-06-10-03-37.gh-issue-139640.gY5oTb.rst
---------
Co-authored-by: Serhiy Storchaka <storchaka@gmail.com>
* [3.14] gh-139748: fix leaks in AC error paths when using unicode FS-based converters (GH-139765)
(cherry picked from commit b04a57deef)
Co-authored-by: Bénédikt Tran <10796600+picnixz@users.noreply.github.com>
gh-137440: Update comment in Python/hamt.c on importing for testing (GH-137441)
Switch from `_testcapi` to `_testinternalcapi`.
(cherry picked from commit 7ab68cd506)
Co-authored-by: Bartosz Sławecki <bartosz@ilikepython.com>
There was a deadlock originally seen by Memray when a daemon thread
enabled or disabled profiling while the interpreter was shutting down.
I think this could also happen with garbage collection, but I haven't
seen that in practice.
The daemon thread could be hung while trying acquire the global rwmutex
that prevents overlapping global and per-interpreter stop-the-world events.
Since it already held the main interpreter's stop-the-world lock, it
also deadlocked the main thread, which is trying to perform interpreter
finalization.
Swap the order of lock acquisition to prevent this deadlock.
Additionally, refactor `_PyParkingLot_Park` so that the global buckets
hashtable is left in a clean state if the thread is hung in
`PyEval_AcquireThread`.
(cherry picked from commit 90fe3250f8)
Co-authored-by: Sam Gross <colesbury@gmail.com>
fix comment reference from man 7 signal to man 7 signal-safety (GH-138554)
(cherry picked from commit 2f5ace780b)
docs: fix comment reference from man 7 signal to man 7 signal-safety
Co-authored-by: mqudah <mohghq@gmail.com>
Call backtrace() once when installing the signal handler to ensure that
libgcc is dynamically loaded outside the signal handler.
This fixes a "signal-unsafe call inside of a signal" TSan error from
test_faulthandler.test_enable_fd.
(cherry picked from commit 11a8652e25)
Co-authored-by: Sam Gross <colesbury@gmail.com>
There were a few thread-safety issues when profiling or tracing all
threads via PyEval_SetProfileAllThreads or PyEval_SetTraceAllThreads:
* The loop over thread states could crash if a thread exits concurrently
(in both the free threading and default build)
* The modification of `c_profilefunc` and `c_tracefunc` wasn't
thread-safe on the free threading build.
(cherry picked from commit a10152f8fd)
Co-authored-by: Sam Gross <colesbury@gmail.com>
Co-authored-by: Petr Viktorin <encukou@gmail.com>
gh-58124: Avoid CP_UTF8 in UnicodeDecodeError (GH-137415)
Fix name of the Python encoding in Unicode errors of the code page
codec: use "cp65000" and "cp65001" instead of "CP_UTF7" and "CP_UTF8"
which are not valid Python code names.
(cherry picked from commit ce1b747ff6)
Co-authored-by: Victor Stinner <vstinner@python.org>
Replacing the slot isn't thread-safe if the GIL is disabled. Don't
require that the slot has been replaced when specializing.
(cherry picked from commit 485b16b4f7)
gh-128639: Don't assume one thread in subinterpreter finalization with fixed daemon thread support (GH-134606)
This reapplies GH-128640.
(cherry picked from commit a64881363b)
Co-authored-by: Peter Bierma <zintensitydev@gmail.com>
gh-112729: Correctly fail when the process is out of memory during interpreter creation (GH-139164)
(cherry picked from commit d06113c7a7)
Co-authored-by: Peter Bierma <zintensitydev@gmail.com>
gh-138756: Fix leak of inittab memory in PyInitConfig_Free() (GH-138792)
(cherry picked from commit 3d521a62e7)
Co-authored-by: Victor Stinner <vstinner@python.org>
gh-138756: Fix memory leak in PyInitConfig_Free() (GH-138759)
Clear also memory of PyConfig members.
(cherry picked from commit 96dee64c73)
Co-authored-by: Victor Stinner <vstinner@python.org>
gh-128627: Use __builtin_wasm_test_function_pointer_signature for Emscripten trampoline (GH-137470)
With https://github.com/llvm/llvm-project/pull/150201 being merged, there is
now a better way to generate the Emscripten trampoline, instead of including
hand-generated binary WASM content. Requires Emscripten 4.0.12.
(cherry picked from commit 2629ee4eb0)
Co-authored-by: Hood Chatham <roberthoodchatham@gmail.com>
Co-authored-by: Sachin Shah <39803835+inventshah@users.noreply.github.com>
Co-authored-by: Hugo van Kemenade <1324225+hugovk@users.noreply.github.com>
Co-authored-by: Petr Viktorin <encukou@gmail.com>
Co-authored-by: R. David Murray <rdmurray@bitdance.com>
Co-authored-by: Kumar Aditya <kumaraditya@python.org>
Co-authored-by: Victor Stinner <vstinner@python.org>
Basic support for pyrepl in Emscripten. Limitations:
* requires JSPI
* no signal handling implemented
As followup work, it would be nice to implement a webworker variant
for when JSPI is not available and proper signal handling.
Because it requires JSPI, it doesn't work in Safari. Firefox requires
setting an experimental flag. All the Chromiums have full support since
May. Until we make it work without JSPI, let's keep the original web_example
around.
(cherry picked from commit c933a6bb32)
Co-authored-by: Hood Chatham <roberthoodchatham@gmail.com>
Co-authored-by: Łukasz Langa <lukasz@langa.pl>
Co-authored-by: Éric <merwok@netwok.org>
This is useful for implementing proper `input()`. It requires the
JavaScript engine to support the wasm JSPI spec which is now stage 4.
It is supported on Chrome since version 137 and on Firefox and node
behind a flag.
We override the `__wasi_fd_read()` syscall with our own variant that
checks for a readAsync operation. If it has it, we use our own async
variant of `fd_read()`, otherwise we use the original `fd_read()`.
We also add a variant of `FS.createDevice()` called
`FS.createAsyncInputDevice()`.
Finally, if JSPI is available, we wrap the `main()` symbol with
`WebAssembly.promising()` so that we can stack switch from `fd_read()`.
If JSPI is not available, attempting to read from an AsyncInputDevice
will raise an `OSError`.
(cherry picked from commit 7ae4749d06)
Co-authored-by: Hood Chatham <roberthoodchatham@gmail.com>
gh-136421: Load `_datetime` static types during interpreter initialization (GH-136583)
`_datetime` is a special module, because it's the only non-builtin C extension that contains static types. As such, it would initialize static types in the module's execution function, which can run concurrently. Since static type initialization is not thread-safe, this caused crashes. This fixes it by moving the initialization of `_datetime`'s static types to interpreter startup (where all other static types are initialized), which is already properly protected through other locks.
(cherry picked from commit a10960699a)
Co-authored-by: Peter Bierma <zintensitydev@gmail.com>
gh-136870: fix data race in `PyThreadState_Clear` on `sys_tracing_threads` (GH-136951)
In free-threading, multiple threads can be cleared concurrently as such the modifications on `sys_tracing_threads` should be done while holding the profile lock, otherwise it can race with other threads setting up profiling.
(cherry picked from commit f183996eb7)
Co-authored-by: Kumar Aditya <kumaraditya@python.org>
