On m68k, an fmove instruction accessing %fpcr may only move from
or to a data register or a memory operand. The constraint "g" also
permits the use of address registers, which is invalid. The correct
constraint is "dm". Beginning with GCC 15, the register allocator
picks an address register in the code which causes SIGILL during
runtime.
(cherry picked from commit 02c085d48b59c00fb7f4454fb13933e1c2c0b01a)
Co-authored-by: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>
Co-authored-by: Michael Karcher <github@mkarcher.dialup.fu-berlin.de>
gh-140815: Fix faulthandler for invalid/freed frame (#140921)
faulthandler now detects if a frame or a code object is invalid or
freed.
Add helper functions:
* _PyCode_SafeAddr2Line()
* _PyFrame_SafeGetCode()
* _PyFrame_SafeGetLasti()
_PyMem_IsPtrFreed() now detects pointers in [-0xff, 0xff] range
as freed.
(cherry picked from commit a84181c31bfc45a1d6bcb1296bd298ad612c54d0)
* gh-90949: add Expat API to prevent XML deadly allocations (CVE-2025-59375) (#139234)
Expose the XML Expat 2.7.2 mitigation APIs to disallow use of
disproportional amounts of dynamic memory from within an Expat
parser (see CVE-2025-59375 for instance).
The exposed APIs are available on Expat parsers, that is,
parsers created by `xml.parsers.expat.ParserCreate()`, as:
- `parser.SetAllocTrackerActivationThreshold(threshold)`, and
- `parser.SetAllocTrackerMaximumAmplification(max_factor)`.
(cherry picked from commit f04bea44c37793561d753dd4ca6e7cd658137553)
(cherry picked from commit 68a1778b7721f3fb853cd3aa674f7039c2a4df36)
Py_RETURN_NONE, Py_RETURN_TRUE and Py_RETURN_FALSE have already been
fixed by commit 9258f3da9175134d03f2c8c7c7eed223802ad945 (issue gh-134989).
(cherry picked from commit c6364775236e3c634c3393c7f50fece50611245f)
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)
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)
On Solaris, `Py_NAN` may expand as a function address instead of a floating-point number.
This amends commit 7a3b03509e5e3e72d8c47137579cccb52548a318.
(cherry picked from commit d54b1091d43b9d8f0da0ba081565bccca3f138fd)
* [3.13] gh-87135: Hang non-main threads that attempt to acquire the GIL during finalization (GH-105805)
Instead of surprise crashes and memory corruption, we now hang threads that attempt to re-enter the Python interpreter after Python runtime finalization has started. These are typically daemon threads (our long standing mis-feature) but could also be threads spawned by extension modules that then try to call into Python. This marks the `PyThread_exit_thread` public C API as deprecated as there is no plausible safe way to accomplish that on any supported platform in the face of things like C++ code with finalizers anywhere on a thread's stack. Doing this was the least bad option.
(cherry picked from commit 8cc5aa47ee464ddfd8da5461edecf4a5c72df2ff)
Co-authored-by: Jeremy Maitin-Shepard <jeremy@jeremyms.com>
Co-authored-by: Gregory P. Smith <greg@krypto.org>
* state "3.13.7 and earlier"
* backport: do not add the deprecated marker
* fix Py_IsFinalizing doc ref
---------
Co-authored-by: Jeremy Maitin-Shepard <jeremy@jeremyms.com>
(cherry picked from commit 698bab5a4031c8f54e04e1dd42bcbe3e4564eba5)
Co-authored-by: Weilin Du <108666168+LamentXU123@users.noreply.github.com>
Co-authored-by: Terry Jan Reedy <tjreedy@udel.edu>
The free threading build uses QSBR to delay the freeing of dictionary
keys and list arrays when the objects are accessed by multiple threads
in order to allow concurrent reads to proceed with holding the object
lock. The requests are processed in batches to reduce execution
overhead, but for large memory blocks this can lead to excess memory
usage.
Take into account the size of the memory block when deciding when to
process QSBR requests.
Also track the amount of memory being held by QSBR for mimalloc pages.
Advance the write sequence if this memory exceeds a limit. Advancing
the sequence will allow it to be freed more quickly.
Process the held QSBR items from the "eval breaker", rather than from
`_PyMem_FreeDelayed()`. This gives a higher chance that the global read
sequence has advanced enough so that items can be freed.
(cherry picked from commit 113de8545ffe74a4a1dddb9351fa1cbd3562b621)
Co-authored-by: Neil Schemenauer <nas-github@arctrix.com>
Co-authored-by: Sam Gross <colesbury@gmail.com>
gh-135607: remove null checking of weakref list in dealloc of extension modules and objects (#135614)
(cherry picked from commit b1056c2a446b43452e457d5fd5f1bde66afd3883)
Co-authored-by: Xuanteng Huang <44627253+xuantengh@users.noreply.github.com>
Co-authored-by: Kumar Aditya <kumaraditya@python.org>
gh-134989: Fix Py_RETURN_NONE in the limited C API (GH-135165)
Fix Py_RETURN_NONE, Py_RETURN_TRUE and Py_RETURN_FALSE macros in the
limited C API 3.11 and older:
Don't treat Py_None, Py_True and Py_False as immortal.
(cherry picked from commit 9258f3da9175134d03f2c8c7c7eed223802ad945)
gh-134989: Implement PyObject_DelAttr() as a macro in the limited C API (GH-135021)
(cherry picked from commit c21113072cd1f0da83729f99d3576647db85d816)
gh-134875: Fix mimallc build error for the old compilers (gh-134994)
(cherry picked from commit b525e31b7fc50e7a498f8b9b16437cb7b9656f6f)
Co-authored-by: Donghee Na <donghee.na@python.org>
gh-129748: Update mimalloc to use atomic store for mi_block_set_nextx (GH-134238)
(cherry picked from commit 317c49622397222b7c7fb49837e6b1fd7e82a80d)
Co-authored-by: Donghee Na <donghee.na@python.org>
If the error handler is used, a new bytes object is created to set as
the object attribute of UnicodeDecodeError, and that bytes object then
replaces the original data. A pointer to the decoded data will became invalid
after destroying that temporary bytes object. So we need other way to return
the first invalid escape from _PyUnicode_DecodeUnicodeEscapeInternal().
_PyBytes_DecodeEscape() does not have such issue, because it does not
use the error handlers registry, but it should be changed for compatibility
with _PyUnicode_DecodeUnicodeEscapeInternal().
(cherry picked from commit 9f69a58623bd01349a18ba0c7a9cb1dad6a51e8e)
Co-authored-by: Serhiy Storchaka <storchaka@gmail.com>
The X/Open curses specification[0] and ncurses documentation[1]
both state that subwindows must be deleted before the main window.
Deleting the windows in the wrong order causes a double-free with
NetBSD's curses implementation.
To fix this, keep track of the original window object in the subwindow
object, and keep a reference to the original for the lifetime of
the subwindow.
[0] https://pubs.opengroup.org/onlinepubs/7908799/xcurses/delwin.html
[1] https://invisible-island.net/ncurses/man/curs_window.3x.html
(cherry picked from commit 0af61fe2f41048d66b0a973bbff056690446d3df)
Co-authored-by: Michael Forney <mforney@mforney.org>
