[issue46159] Segfault when using trace functions in 3.11a3
Quentin Pradet added the comment:
Thanks, you're right, I ran `git bisect` on Linux and the commit that causes
the issue is
https://github.com/python/cpython/commit/135cabd328504e1648d17242b42b675cdbd0193b
("Copy free variables in bytecode to allow calls to inner functions to be
specialized") from https://bugs.python.org/issue44525
--
___
Python tracker
<https://bugs.python.org/issue46159>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46159] Segfault when using trace functions in 3.11a3
Quentin Pradet added the comment: The ABI between alpha 2 and alpha 3 changed, see https://bugs.python.org/issue46320. If pip built (say) cffi in CI for alpha2 and put it in the cache, then it reused that wheel for alpha3 and the segfault is expected. -- nosy: +Quentin.Pradet ___ Python tracker <https://bugs.python.org/issue46159> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46320] runtime/interp/thread state refactoring leads to segmentation fault
Quentin Pradet added the comment: Oh my god. You're right, I had a cffi wheel compiled for Python 3.11 before that commit. But the wheel was not coming from PyPI, it was coming from pip's own cache! And we recently enabled pip's cache in GitHub Actions too. So the wheel compiled locally for alpha 2 got reused for alpha 3, and . Sorry for the noise but thanks a lot for your help, this was really baffling. Closing! -- stage: needs patch -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue46320> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46320] runtime/interp/thread state refactoring leads to segmentation fault
Quentin Pradet added the comment: We haven't opened an issue for this, but discussed it in Discord, sorry. It also does not always crash on GitHub Actions. Here's an example of a crash: https://github.com/urllib3/urllib3/runs/4740730329?check_suite_focus=true If nox can't find your Python version and `nox --no-venv -Rs test-3.11` does not run your version of Python 3.11, you can always execute those commands directly: pip install -r dev-requirements.txt pip install ".[socks,secure,brotli]" pytest If that does not crash on your system, I'd appreciate if you could tell me how I could help get this fixed besides simplifying the reproducer. Thanks. -- ___ Python tracker <https://bugs.python.org/issue46320> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46320] runtime/interp/thread state refactoring leads to segmentation fault
Quentin Pradet added the comment: Yes, exactly. `pip install nox && nox -Rs test-3.11`. My reproducer is still too big to be useful, and I failed to reproduce this on Docker. If you can't reproduce, I'll work on the reproducer more. Thanks! -- ___ Python tracker <https://bugs.python.org/issue46320> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46008] Prepare runtime/interp/thread state and init for upcoming changes.
Quentin Pradet added the comment: For what it's worth, this refactoring led to a 100% reproducible crash on my Fedora laptop: https://bugs.python.org/issue46320. (And led to various crashes in urllib3's CI, but they were more random.) -- nosy: +Quentin.Pradet ___ Python tracker <https://bugs.python.org/issue46008> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46320] runtime/interp/thread state refactoring leads to segmentation fault
Quentin Pradet added the comment: Sorry, I pasted the same crash twice. Here's the segmentation fault in `selectors`: ``` = test session starts = platform linux -- Python 3.11.0a2+, pytest-6.2.5, py-1.11.0, pluggy-1.0.0 rootdir: /home/q/pub/urllib3, configfile: setup.cfg collected 1 item test/test_reproduce.py Fatal Python error: Segmentation fault Thread 0x7f9683378640 (most recent call first): File "/home/q/pub/install/lib/python3.11/selectors.py", line 416 in select File "/home/q/pub/install/lib/python3.11/asyncio/base_events.py", line 1822 in _run_once File "/home/q/pub/install/lib/python3.11/asyncio/base_events.py", line 591 in run_forever File "/home/q/pub/urllib3/venv/lib/python3.11/site-packages/tornado/platform/asyncio.py", line 199 in start File "/home/q/pub/install/lib/python3.11/threading.py", line 968 in run File "/home/q/pub/install/lib/python3.11/threading.py", line 1031 in _bootstrap_inner File "/home/q/pub/install/lib/python3.11/threading.py", line 988 in _bootstrap Extension modules: tornado.speedups, _brotli, _cffi_backend (total: 3) zsh: segmentation fault (core dumped) pytest ``` (Those results are produced with https://github.com/python/cpython/commit/32a67246b0d1e08cd50fc3bfa58052cfeb515b2e) -- ___ Python tracker <https://bugs.python.org/issue46320> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46320] runtime/interp/thread state refactoring leads to segmentation fault
New submission from Quentin Pradet : Since https://github.com/python/cpython/commit/32a67246b0d1e08cd50fc3bfa58052cfeb515b2e which was introduced through https://bugs.python.org/issue46008 and shipped as part of alpha 3, the urllib3 test suite reliably crashes on Fedora 35 (ie. gives a segfault). I've narrowed the reproducer code down to https://github.com/pquentin/urllib3/blob/segfault/test/test_reproduce.py, but that still requires cffi, pyOpenSSL and Tornado. The segfault either happens in the `ssl` module or the `selectors` module: ``` = test session starts = platform linux -- Python 3.11.0a2+, pytest-6.2.5, py-1.11.0, pluggy-1.0.0 rootdir: /home/q/pub/urllib3, configfile: setup.cfg collected 1 item test/test_reproduce.py Fatal Python error: Segmentation fault Thread 0x7fee9a250640 (most recent call first): File "/home/q/pub/install/lib/python3.11/ssl.py", line 1346 in do_handshake File "/home/q/pub/urllib3/venv/lib/python3.11/site-packages/tornado/iostream.py", line 1391 in _do_ssl_handshake File "/home/q/pub/urllib3/venv/lib/python3.11/site-packages/tornado/iostream.py", line 1478 in _handle_read File "/home/q/pub/urllib3/venv/lib/python3.11/site-packages/tornado/iostream.py", line 696 in _handle_events File "/home/q/pub/urllib3/venv/lib/python3.11/site-packages/tornado/platform/asyncio.py", line 189 in _handle_events File "/home/q/pub/install/lib/python3.11/asyncio/events.py", line 80 in _run File "/home/q/pub/install/lib/python3.11/asyncio/base_events.py", line 1858 in _run_once File "/home/q/pub/install/lib/python3.11/asyncio/base_events.py", line 591 in run_forever File "/home/q/pub/urllib3/venv/lib/python3.11/site-packages/tornado/platform/asyncio.py", line 199 in start File "/home/q/pub/install/lib/python3.11/threading.py", line 968 in run File "/home/q/pub/install/lib/python3.11/threading.py", line 1031 in _bootstrap_inner File "/home/q/pub/install/lib/python3.11/threading.py", line 988 in _bootstrap Extension modules: tornado.speedups, _brotli, _cffi_backend (total: 3) zsh: segmentation fault (core dumped) pytest ``` ``` = test session starts = platform linux -- Python 3.11.0a2+, pytest-6.2.5, py-1.11.0, pluggy-1.0.0 rootdir: /home/q/pub/urllib3, configfile: setup.cfg collected 1 item test/test_reproduce.py Fatal Python error: Segmentation fault Thread 0x7fee9a250640 (most recent call first): File "/home/q/pub/install/lib/python3.11/ssl.py", line 1346 in do_handshake File "/home/q/pub/urllib3/venv/lib/python3.11/site-packages/tornado/iostream.py", line 1391 in _do_ssl_handshake File "/home/q/pub/urllib3/venv/lib/python3.11/site-packages/tornado/iostream.py", line 1478 in _handle_read File "/home/q/pub/urllib3/venv/lib/python3.11/site-packages/tornado/iostream.py", line 696 in _handle_events File "/home/q/pub/urllib3/venv/lib/python3.11/site-packages/tornado/platform/asyncio.py", line 189 in _handle_events File "/home/q/pub/install/lib/python3.11/asyncio/events.py", line 80 in _run File "/home/q/pub/install/lib/python3.11/asyncio/base_events.py", line 1858 in _run_once File "/home/q/pub/install/lib/python3.11/asyncio/base_events.py", line 591 in run_forever File "/home/q/pub/urllib3/venv/lib/python3.11/site-packages/tornado/platform/asyncio.py", line 199 in start File "/home/q/pub/install/lib/python3.11/threading.py", line 968 in run File "/home/q/pub/install/lib/python3.11/threading.py", line 1031 in _bootstrap_inner File "/home/q/pub/install/lib/python3.11/threading.py", line 988 in _bootstrap Extension modules: tornado.speedups, _brotli, _cffi_backend (total: 3) zsh: segmentation fault (core dumped) pytest ``` I can work on a better reproducer, but thought this was already interesting as https://github.com/python/cpython/pull/29977 states there should have been zero change in behavior. -- components: Interpreter Core messages: 410166 nosy: Quentin.Pradet, SethMichaelLarson, eric.snow priority: normal severity: normal status: open title: runtime/interp/thread state refactoring leads to segmentation fault type: crash versions: Python 3.11 ___ Python tracker <https://bugs.python.org/issue46320> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43522] SSLContext.hostname_checks_common_name appears to have no effect
Quentin Pradet added the comment: Thank you for the quick fix! Both the reproducer and the urllib3 test suite run fine with this change. However, we can't trust `HAS_NEVER_CHECK_COMMON_NAME` anymore, because it will be True in Python versions where `hostname_checks_common_name` does not work. Is it possible to have, uh, `REALLY_HAS_NEVER_CHECK_COMMON_NAME_I_PROMISE` or something like that? :D It could even be private. Otherwise, we will only be able to use `hostname_checks_common_name` in Python 3.10.0a7+. -- ___ Python tracker <https://bugs.python.org/issue43522> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43522] SSLContext.hostname_checks_common_name appears to have no effect
Change by Quentin Pradet : Added file: https://bugs.python.org/file49883/server.key ___ Python tracker <https://bugs.python.org/issue43522> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43522] SSLContext.hostname_checks_common_name appears to have no effect
Change by Quentin Pradet : Added file: https://bugs.python.org/file49881/client.pem ___ Python tracker <https://bugs.python.org/issue43522> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43522] SSLContext.hostname_checks_common_name appears to have no effect
Change by Quentin Pradet : Added file: https://bugs.python.org/file49882/server.pem ___ Python tracker <https://bugs.python.org/issue43522> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43522] SSLContext.hostname_checks_common_name appears to have no effect
Change by Quentin Pradet : Added file: https://bugs.python.org/file49880/app.py ___ Python tracker <https://bugs.python.org/issue43522> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43522] SSLContext.hostname_checks_common_name appears to have no effect
New submission from Quentin Pradet :
urllib3 is preparing a v2 with various SSL improvements, such as leaning on the
ssl module to match hostnames when possible and reject certificates without a
SAN. See
https://urllib3.readthedocs.io/en/latest/v2-roadmap.html#modern-security-by-default
for more details.
For this reason, we want to set `hostname_checks_common_name` to False on
Python 3.7+ and OpenSSL 1.1.0+. (In other cases, we use a modified version of
`ssl.match_hostname` that does not consider common names.)
I would expect that setting `hostname_checks_common_name` to False would
rejects certificates without SANs, but that does not appear to be the case. I
used the following Python code:
import socket
import ssl
print(ssl.OPENSSL_VERSION)
hostname = 'localhost'
context = ssl.create_default_context()
context.load_verify_locations("client.pem")
context.hostname_checks_common_name = False
with socket.create_connection((hostname, 8000)) as sock:
with context.wrap_socket(sock, server_hostname=hostname) as ssock:
assert "subjectAltName" not in ssock.getpeercert()
which prints `OpenSSL 1.1.1i 8 Dec 2020` and does not fail as expected. I'm
testing this on macOS 11.2.2 but this currently breaks our test suite on
Ubuntu, Windows and macOS, including on Python 3.10, see
https://github.com/urllib3/urllib3/runs/2122811894?check_suite_focus=true.
To reproduce this, I used trustme (https://trustme.readthedocs.io/en/latest/).
I modified the code to not include a SAN at all and ran `gunicorn --keyfile
server.key --certfile server.pem app:app`, with app being the Flask quickstart
application. I'll try to attach all those files if I manage to do it.
What am I missing?
--
assignee: christian.heimes
components: SSL
files: no_san_ignored.py
messages: 388875
nosy: Quentin.Pradet, christian.heimes
priority: normal
severity: normal
status: open
title: SSLContext.hostname_checks_common_name appears to have no effect
versions: Python 3.10
Added file: https://bugs.python.org/file49879/no_san_ignored.py
___
Python tracker
<https://bugs.python.org/issue43522>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27594] Assertion failure when running "test_ast" tests with coverage.
Quentin Pradet added the comment: Thanks levkivskyi, it fixed the issue for me! -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue27594> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27594] Assertion failure when running "test_ast" tests with coverage.
Changes by Quentin Pradet <quentin.pra...@gmail.com>: -- nosy: +Quentin.Pradet ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue27594> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26220] Unicode HOWTO references a question mark that isn't in snippet
New submission from Quentin Pradet:
>From https://docs.python.org/3.6/howto/unicode.html#the-string-type:
> The following examples show the differences::
>
> >>> b'\x80abc'.decode("utf-8", "strict") #doctest: +NORMALIZE_WHITESPACE
> Traceback (most recent call last):
> ...
> UnicodeDecodeError: 'utf-8' codec can't decode byte 0x80 in position 0:
> invalid start byte
> >>> b'\x80abc'.decode("utf-8", "replace")
> '\ufffdabc'
> >>> b'\x80abc'.decode("utf-8", "backslashreplace")
> '\\x80abc'
> >>> b'\x80abc'.decode("utf-8", "ignore")
> 'abc'
>
> (In this code example, the Unicode replacement character has been replaced by
> a question mark because it may not be displayed on some systems.)
I think the whole sentence after the snippet can be removed because this is
exactly what Python 3.2+ outputs. It looks like the commit which added this
sentence dates from Python 3.1:
https://github.com/python/cpython/commit/34d4c82af56ebc1b65514a118f0ec7feeb8e172f,
but another commit around Python 3.3 removed it:
https://github.com/python/cpython/commit/63172c46706ae9b2a3bc80d639504a57fff4e716.
--
assignee: docs@python
components: Documentation
messages: 259034
nosy: Quentin.Pradet, docs@python
priority: normal
severity: normal
status: open
title: Unicode HOWTO references a question mark that isn't in snippet
versions: Python 3.2, Python 3.3, Python 3.4, Python 3.5, Python 3.6
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue26220>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21049] Warning at interpreter exit triggers flood of “ImportWarning: sys.meta_path is empty”
Quentin Pradet added the comment: Martin, yes, I'd be glad to see a fix if it's not too complicated. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21049 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21052] Consider dropping ImportWarning for empty sys.path_hooks and sys.meta_path
Changes by Quentin Pradet quentin.pra...@gmail.com: -- nosy: +Quentin.Pradet ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21052 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21049] Warning at interpreter exit triggers flood of “ImportWarning: sys.meta_path is empty”
Quentin Pradet added the comment: I've also been affected by this when testing integration with a third-party library (NLTK). NLTK does need to be fixed, but the ResourceWarning already say so. The new one-liner doesn't seem contrived to me. -- nosy: +Quentin.Pradet ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21049 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18983] Specify time unit for timeit CLI
Quentin Pradet added the comment: The branch appears to exist now. -- nosy: +Quentin.Pradet ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18983 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
