* Move co_extra_freefuncs to interpreter state to avoid crashes in
multi-threaded scenarios involving deletion of code objects
* Don't require that extra be zero initialized
* Build test list instead of defining empty test class
* Ensure extra is always assigned on success
* Keep the old fields in the thread state object, just don't use them
Add new linked list of code extra objects on a per-interpreter basis
so that interpreter state size isn't changed
* Rename __PyCodeExtraState_Get and add comment about it going away in 3.7
Fix sort order of import's in test_code.py
* Remove an extraneous space
* Remove docstrings for comments
* Touch up formatting
* Fix casing of coextra local
* Fix casing of another variable
* Prefix PyCodeExtraState with __ to match C API for getting it
* Update NEWS file for bpo-30604
This PR contains two updates to typing module:
- Support ContextManager on all versions (original PR by Jelle Zijlstra).
- Add generic AsyncContextManager..
(cherry picked from commit 29fda8db16)
* bpo-29406: asyncio SSL contexts leak sockets after calling close with certain servers (#409)
(cherry picked from commit a608d2d5a7)
* [3.6] bpo-29406: asyncio SSL contexts leak sockets after calling close with certain servers (GH-409)
* asyncio SSL contexts leak sockets after calling close with certain servers
* cleanup _shutdown_timeout_handle on _fatal_error.
(cherry picked from commit a608d2d5a7)
Before, it was possible to get the following sequence of
events (especially on Windows, where the C-level signal handler for
SIGINT is run in a separate thread):
- SIGINT arrives
- trip_signal is called
- trip_signal writes to the wakeup fd
- the main thread wakes up from select()-or-equivalent
- the main thread checks for pending signals, but doesn't see any
- the main thread drains the wakeup fd
- the main thread goes back to sleep
- trip_signal sets is_tripped=1 and calls Py_AddPendingCall to notify
the main thread the it should run the Python-level signal handler
- the main thread doesn't notice because it's asleep
This has been causing repeated failures in the Trio test suite:
https://github.com/python-trio/trio/issues/119
(cherry picked from commit 4ae0149697)
(cherry picked from commit 054e09147a)
* bpo-30290: IDLE: Refactor help_about to PEP8 names (#1714)
Patch by Cheryl Sabella.
(cherry picked from commit 5a346d5dbc)
* IDLE test_help_about: edit and add test. (#1838)
Coverage is now 100%
(cherry picked from commit eca7da0f13)
contextlib.AbstractContextManager now supports anti-registration
by setting __enter__ = None or __exit__ = None, following the pattern
introduced in bpo-25958..
(cherry picked from commit 57161aac5e)
This will allow for centralized management of the Codecov config to prevent skew as well as easier management going forward.
Closes python/core-workflowGH-81.
(cherry picked from commit 11ffb4543b)
If we have a chain of generators/coroutines that are 'yield from'ing
each other, then resuming the stack works like:
- call send() on the outermost generator
- this enters _PyEval_EvalFrameDefault, which re-executes the
YIELD_FROM opcode
- which calls send() on the next generator
- which enters _PyEval_EvalFrameDefault, which re-executes the
YIELD_FROM opcode
- ...etc.
However, every time we enter _PyEval_EvalFrameDefault, the first thing
we do is to check for pending signals, and if there are any then we
run the signal handler. And if it raises an exception, then we
immediately propagate that exception *instead* of starting to execute
bytecode. This means that e.g. a SIGINT at the wrong moment can "break
the chain" – it can be raised in the middle of our yield from chain,
with the bottom part of the stack abandoned for the garbage collector.
The fix is pretty simple: there's already a special case in
_PyEval_EvalFrameEx where it skips running signal handlers if the next
opcode is SETUP_FINALLY. (I don't see how this accomplishes anything
useful, but that's another story.) If we extend this check to also
skip running signal handlers when the next opcode is YIELD_FROM, then
that closes the hole – now the exception can only be raised at the
innermost stack frame.
This shouldn't have any performance implications, because the opcode
check happens inside the "slow path" after we've already determined
that there's a pending signal or something similar for us to process;
the vast majority of the time this isn't true and the new check
doesn't run at all..
(cherry picked from commit ab4413a7e9)
* RFC 1750 has been been obsoleted by RFC 4086.
* RFC 3280 has been obsoleted by RFC 5280.
* RFC 4366 has been obsoleted by RFC 6066.
(cherry picked from commit 63c2c8ac17)
* bpo-29259: Remove unused func parameter of _PyStack_UnpackDict()
* bpo-29286: Change _PyStack_UnpackDict() prototype to be able to
notify of failure when args is NULL. _PyStack_UnpackDict() now
returns -1 on error.
'invalid character in identifier' now is raised instead of
'f-string: empty expression not allowed' if a subexpression contains
only whitespaces and they are not accepted by Python parser.
(cherry picked from commit 2e9cd58)
On Windows, subprocess.Popen.communicate() now also ignore EINVAL
on stdin.write() if the child process is still running but closed the
pipe.
(cherry picked from commit d52aa31378)
Fix a reference leak in _io._WindowsConsoleIO: PyUnicode_FSDecoder()
always initialize decodedname when it succeed and it doesn't clear
input decodedname object.
(cherry picked from commit 29adc13bd7)
* Fix bpo-30584
* Adding a comment mentionning the bpo and explaining what is the identifier
* Add Denis Osipov to Misc/ACKS
(cherry picked from commit 897bba7563)
If pass a server_hostname= that fails IDNA decoding to SSLContext.wrap_socket or SSLContext.wrap_bio, then the SSLContext object had a spurious Py_DECREF called on it, eventually leading to segfaults.
(cherry picked from commit 65ece7ca23)