[3.13] gh-139927: Fix test_embed on OpenIndiana (GH-142514) (#142521)
gh-139927: Fix test_embed on OpenIndiana (GH-142514)
Avoid swprintf() function in Programs/_testembed.c since it doesn't
work as expected on OpenIndiana.
(cherry picked from commit c76cfe8d89c5f44b6a012d24c0e14b45eab16b90)
Co-authored-by: Victor Stinner <vstinner@python.org>
[3.13] gh-142454: Make the JIT digest more deterministic by sorting the files in Tools/jit (GH-142455) (#142484)
gh-142454: Make the JIT digest more deterministic by sorting the files in Tools/jit (GH-142455)
(cherry picked from commit bcf90de8ba2ea087540a5f632656ef880ee46b5c)
Co-authored-by: Miro Hrončok <miro@hroncok.cz> Co-authored-by: Ken Jin <kenjin4096@gmail.com>
[3.13] gh-112527: Fix help text for required options in argparse (GH-112528) (GH-142477)
For optional arguments with required=True, the ArgumentDefaultsHelpFormatter
would always add a " (default: None)" to the end of the help text.
Since that's a bit misleading, it is removed with this commit.
(cherry picked from commit 1adb17b1a26e1547d14ca15f915e605cfdda3edd)
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>
Co-authored-by: Ivo Bellin Salarin <nilleb@users.noreply.github.com> Co-authored-by: Martin Panter <vadmium@users.noreply.github.com> Co-authored-by: Ivo Bellin Salarin <ivo@nilleb.com>
dr-carlos [Mon, 8 Dec 2025 18:46:55 +0000 (05:16 +1030)]
[3.13] gh-141732: Fix ExceptionGroup repr changing when original exception sequence is mutated (GH-141736) (#142391)
* [3.13] gh-141732: Fix `ExceptionGroup` repr changing when original exception sequence is mutated (GH-141736)
(cherry picked from commit ff2577f56eb2170ef0afafa90f78c693df7ca562)
[3.13] gh-142006: Fix HeaderWriteError in email.policy.default caused by extra newline (GH-142008) (#142362)
gh-142006: Fix HeaderWriteError in email.policy.default caused by extra newline (GH-142008)
RDM: This fixes a subtle folding error that showed up when a token exactly filled a line and was followed by whitespace and a token with no folding whitespace that was longer than a line. In this particular circumstance the whitespace after the first token got pushed on to the next line, and then stolen to go in front of the next unfoldable token...leaving a completely empty line in the line buffer. That line got turned in to a newline, which is RFC illegal, and the newish security check caught it. The fix is to just delete that empty line from the buffer.
(cherry picked from commit 07eff899d8a8ee4c4b1be7cb223fe25687f6216c)
[3.13] gh-140482: Avoid changing terminal settings in test_pty (gh-142202) (gh-142238)
The previous test_spawn_doesnt_hang test had a few problems:
* It would cause ENV CHANGED failures if other tests were running
concurrently due to stty changes
* Typing while the test was running could cause it to fail
(cherry picked from commit c0c65141b37029bfb364094a6dfb4c75ebf8359e)
[3.13] gh-119452: Fix a potential virtual memory allocation denial of service in http.server (GH-142216) (#142296)
[3.14] gh-119452: Fix a potential virtual memory allocation denial of service in http.server (GH-142216)
The CGI server on Windows could consume the amount of memory specified
in the Content-Length header of the request even if the client does not
send such much data. Now it reads the POST request body by chunks,
therefore the memory consumption is proportional to the amount of sent
data.
(cherry picked from commit 0e4f4f1a4633f2d215fb5a803cae278aeea31845)
Co-authored-by: Serhiy Storchaka <storchaka@gmail.com> Co-authored-by: Hugo van Kemenade <1324225+hugovk@users.noreply.github.com>
[3.13] gh-119451: Fix a potential denial of service in http.client (GH-119454) (#142139)
gh-119451: Fix a potential denial of service in http.client (GH-119454)
Reading the whole body of the HTTP response could cause OOM if
the Content-Length value is too large even if the server does not send
a large amount of data. Now the HTTP client reads large data by chunks,
therefore the amount of consumed memory is proportional to the amount
of sent data.
(cherry picked from commit 5a4c4a033a4a54481be6870aa1896fad732555b5)
Difference from the original commit: the default in 3.14 is to use
the simpler original protocol (except for filenames with newlines).
(cherry picked from commit f130b06da30616dd4dae363c7d8af79b540a7971)
This fixes a regression introduced in gh-140558. The interpreter would
crash if we inserted a non `str` key into a split table that matches an
existing key.
(cherry picked from commit 547d8daf780646e2800bec598ed32085817c8606)
Tian Gao [Tue, 2 Dec 2025 05:07:52 +0000 (21:07 -0800)]
[3.13] gh-59000: Fix pdb breakpoint resolution for class methods when… (#142172)
* [3.13] gh-59000: Fix pdb breakpoint resolution for class methods when module not imported (GH-141949)
(cherry picked from commit 5e58548ebe8f7ac8c6cb0bad775912caa4090515)
The GC for the free threaded build would get slower with each collection due
to effectively double counting objects freed by the GC.
(cherry picked from commit eb892868b31322d7cf271bc25923e14b1f67ae38)
[3.13] gh-119342: Fix a potential denial of service in plistlib (GH-119343) (GH-142144)
Reading a specially prepared small Plist file could cause OOM because file's
read(n) preallocates a bytes object for reading the specified amount of
data. Now plistlib reads large data by chunks, therefore the upper limit of
consumed memory is proportional to the size of the input file.
(cherry picked from commit 694922cf40aa3a28f898b5f5ee08b71b4922df70)
[3.13] gh-119452: Fix a potential virtual memory allocation denial of service in http.server (GH-119455) (GH-142130)
The CGI server on Windows could consume the amount of memory specified
in the Content-Length header of the request even if the client does not
send such much data. Now it reads the POST request body by chunks,
so that the memory consumption is proportional to the amount of sent
data.
(cherry picked from commit 29c657a1f231c0908796e0c9ff6967e15ab20d9b)
[3.13] gh-87512: Fix `subprocess` using `timeout=` on Windows blocking with a large `input=` (GH-142058) (#142069)
gh-87512: Fix `subprocess` using `timeout=` on Windows blocking with a large `input=` (GH-142058)
On Windows, Popen._communicate() previously wrote to stdin synchronously, which could block indefinitely if the subprocess didn't consume input= quickly and the pipe buffer filled up. The timeout= parameter was only checked when joining the reader threads, not during the stdin write.
This change moves the Windows stdin writing to a background thread (similar to how stdout/stderr are read in threads), allowing the timeout to be properly enforced. If timeout expires, TimeoutExpired is raised promptly and the writer thread continues in the background. Subsequent calls to communicate() will join the existing writer thread.
Adds test_communicate_timeout_large_input to verify that TimeoutExpired is raised promptly when communicate() is called with large input and a timeout, even when the subprocess doesn't consume stdin quickly.
This test already passed on POSIX (where select() is used) but failed on Windows where the stdin write blocks without checking the timeout.
(cherry picked from commit 5b1862bdd8021b5295df95d730c2d2efa827fa88)
Co-authored-by: Gregory P. Smith <68491+gpshead@users.noreply.github.com> Co-authored-by: Claude Opus 4.5 <noreply@anthropic.com>
[3.13] gh-141473: Fix subprocess.Popen.communicate to send input to stdin upon a subsequent post-timeout call (GH-141477) (#142060)
* gh-141473: Fix subprocess.Popen.communicate to send input to stdin upon a subsequent post-timeout call (GH-141477)
* gh-141473: Fix subprocess.Popen.communicate to send input to stdin
* Docs: Clarify that `input` is one time only on `communicate()`
* NEWS entry
* Add a regression test.
GH-134453: Fix subprocess memoryview input handling on POSIX (GH-134949)
Fix inconsistent subprocess.Popen.communicate() behavior between Windows
and POSIX when using memoryview objects with non-byte elements as input.
On POSIX systems, the code was incorrectly comparing bytes written against
element count instead of byte count, causing data truncation for large
inputs with non-byte element types.
Changes:
- Cast memoryview inputs to byte view when input is already a memoryview
- Fix progress tracking to use len(input_view) instead of len(self._input)
- Add comprehensive test coverage for memoryview inputs
🤖 Generated with [Claude Code](https://claude.ai/code)
* old-man-yells-at-ReST
* Update 2025-05-30-18-37-44.gh-issue-134453.kxkA-o.rst
* assertIsNone review feedback
* fix memoryview_nonbytes test to fail without our fix on main, and have a nicer error.
[3.13] gh-141907: Better handle support for SHA3 for test_hashlib (GH-141908) (#141919)
gh-141907: Better handle support for SHA3 for test_hashlib (GH-141908)
* test_hashlib: better handle support for SHA3
It's possible that the SSL library supports only SHA3 algo and doesn't
have SHAKE one.
The current test wrongly detect this and set both HASH and HASHXOF to
None expecting to have the extra SHA3 attributes present but this should
only be true for SHAKE algo.
To better handle this, move the HASH condition to a dedicated try-expect
condition and check if HASHXOF is None in the relevant code effectively
checking if SHA3 is supported by the SSL library but SHAKE algo needs to
use the sha3module one.
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com> Co-authored-by: Christian Marangi <ansuelsmth@gmail.com> Co-authored-by: Gregory P. Smith <greg@krypto.org>
[3.13] gh-129441: Fix some flakiness in test_instrumentation (gh-141881) (gh-141914)
Most of the `self.assertTrue(self.called)` checks are flaky because
the worker threads may sometimes finish before the main thread calls
`self.during_threads()`.
(cherry picked from commit 71126ab19c76d8227fc3b9c7c59b957ca82af4dd)
[3.13] gh-106318: Add example for str.isascii() (GH-137558) (#141899)
Co-authored-by: Adorilson Bezerra <adorilson@gmail.com> Co-authored-by: Stan Ulbrych <89152624+StanFromIreland@users.noreply.github.com> Co-authored-by: Hugo van Kemenade <1324225+hugovk@users.noreply.github.com>
[3.13] gh-135335: Simplify preload regression test using __main__ (GH-138686) (#141887)
gh-135335: Simplify preload regression test using __main__ (GH-138686)
Simplify preload regression test using `__main__`
With the fix for gh-126631 `__main__` modules can be preloaded and the regression
test for gh-135335 can be simplified to just use a self-contained script rather
than requiring a module.
Sam Gross [Sun, 23 Nov 2025 15:30:37 +0000 (10:30 -0500)]
[3.13] gh-120158: Fix inconsistent monitoring state when setting events too frequently (gh-141845) (gh-141880)
If we overflowed the global version counter (i.e., after 2*24 calls to
`_PyMonitoring_SetEvents`), we bailed out after setting global monitoring
events but before instrumenting code objects, which led to assertion errors
later on.
Also add a `time.sleep()` to `test_free_threading.test_monitoring` to avoid
overflowing the global version counter.
(cherry picked from commit e457d60daafe66534283e0f79c81517634408e57)
[3.13] gh-141801: Use accessors for ASN1_STRING fields in libssl (GH-141802) (#141848)
gh-141801: Use accessors for ASN1_STRING fields in libssl (GH-141802)
* gh-141801: Use accessors for ASN1_STRING fields
While ASN1_STRING is currently exposed, it is better to use the
accessors. See https://github.com/openssl/openssl/issues/29117 where, if
the type were opaque, OpenSSL's X509 objects could be much more
memory-efficient.
[3.13] gh-101100: Fix all Sphinx warnings in `Doc/library/subprocess.rst` (GH-139576) (#139788)
Co-authored-by: Stan Ulbrych <89152624+StanFromIreland@users.noreply.github.com> Co-authored-by: Hugo van Kemenade <1324225+hugovk@users.noreply.github.com>
Co-authored-by: Peter Bierma <zintensitydev@gmail.com> Co-authored-by: Stan Ulbrych <89152624+StanFromIreland@users.noreply.github.com> Co-authored-by: Victor Stinner <vstinner@python.org>
Victor Stinner [Wed, 19 Nov 2025 14:28:31 +0000 (15:28 +0100)]
[3.13] gh-141570: can_colorize: Expect fileno() to raise OSError, as documented (#141716) (#141748)
gh-141570: can_colorize: Expect fileno() to raise OSError, as documented (#141716)
In Fedora, we've been given a slightly incomplete reproducer for a problematic
Python 3.14 color-related change in argparse that leads to an exception when
Python is used from mod_wsgi: https://bugzilla.redhat.com/2414940
mod_wsgi replaces sys.stdout with a custom object that raises OSError on .fileno():
projects / thirdparty / Python / cpython.git / log
