gh-140257: fix data race on eval_breaker during finalization (GH-140265)
(cherry picked from commit c8729c9909e150989050ce2a435d018955bea41d)
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 32c264982ec67460642b907dabc3304019318291)
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 279db6bede30be3a1b86803585eb4404d27800da)
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 b04a57deef66ce08233be57d1ab5873388df2cea)
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 7ab68cd50658f76abc9e0f12e6212736e2440720)
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 90fe3250f82712b61630d636246c92df7c40c816)
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 2f5ace780ba3880ce07c4aacbda08ebba36e3b4d)
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 11a8652e25341e696b06d8dc7a18e8c3ee8059e4)
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 a10152f8fd0f4b291e53d646cffe22fbeec73e1e)
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 ce1b747ff68754635b7b12870dfc527184ee3b39)
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 485b16b4f7b28cefdfb524c2869d473078e349bf)
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 a64881363b836b95fb4512a5689d69c1aa07ecb8)
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 d06113c7a7cac76a28847702685e601b79f71bf8)
Co-authored-by: Peter Bierma <zintensitydev@gmail.com>
gh-138756: Fix leak of inittab memory in PyInitConfig_Free() (GH-138792)
(cherry picked from commit 3d521a62e7c377ac518c9f0326a88be204f0e3aa)
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 96dee64c73531325daa9e048b3c18212f5eadd98)
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 2629ee4eb0e9f66f28772cb4b4cc44ebe6de79ad)
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 c933a6bb329bb97bc7e448388dad1b74f7ca4baa)
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 7ae4749d064bd49b0dd96172fee20c1f1678d9e9)
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 a10960699a2b3e4e62896331c4f9cfd162ebf440)
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 f183996eb77fd2d5662c62667298c292c943ebf5)
Co-authored-by: Kumar Aditya <kumaraditya@python.org>
gh-134411: assert `PyLong_FromLong(x) != NULL` when `x` is known to be small (GH-134415)
Since `PyLong_From Long(PY_MONITORING_DEBUGGER_ID)` falls to `small_int` case and can't return `NULL`. Added `assert`s for extra confidence.
https://github.com/python/cpython/issues/134411#issuecomment-2897653868
(cherry picked from commit cf19b6435d02dd7be11b84a44f4a8a9f1a935b15)
Co-authored-by: Sergey Muraviov <smurav@mail.ru>
Provide a stub implementation of umask that is enough to get some tests passing.
More work is needed upstream in Emscripten to make all umask tests to pass.
(cherry picked from commit 12e52cad718723636a96042f9399634392285c44)
Co-authored-by: Hood Chatham <roberthoodchatham@gmail.com>
Corrects the handling of getuid on emscripten, which was consistently reporting as 0.
(cherry picked from commit e81c4e84b3a8688a367099e3adf9b2fcf914447f)
Co-authored-by: Hood Chatham <roberthoodchatham@gmail.com>
gh-136517: Print uncollectable objects if DEBUG_UNCOLLECTABLE mode was set (GH-136518)
(cherry picked from commit c560df9658f1a24edea995fe6f9c84c55b37cfb3)
Co-authored-by: Sergey Miryanov <sergey.miryanov@gmail.com>
gh-136541: Fix several problems of perf trampolines in x86_64 and aarch64 (GH-136500)
This commit fixes the following problems:
* The x86_64 trampolines are not preserving frame pointers
* The hardcoded offsets to the code segment from the FDE only worked properly for x64_64
* The CIE data was not following conventions of aarch64
* The eh_frame for aarch64 was not fully correct
(cherry picked from commit 236f733d8ffb3d587e1167fa0a0248c24512e7fd)
Co-authored-by: Pablo Galindo Salgado <Pablogsal@gmail.com>
gh-91048: Revert the memory cache removal for remote debugging (GH-136440)
(cherry picked from commit 77d25e5b169f7c306d3a6d9ca6777c0a0be80d8f)
gh-91048: Reintroduce the memory cache for remote debugging
Co-authored-by: Pablo Galindo Salgado <Pablogsal@gmail.com>
