[issue33063] failed to build _ctypes: undefined reference to `ffi_closure_FASTCALL'
Change by Fantix King : -- nosy: +fantix nosy_count: 3.0 -> 4.0 pull_requests: +25844 stage: -> patch review pull_request: https://github.com/python/cpython/pull/8620 ___ Python tracker <https://bugs.python.org/issue33063> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39951] Ignore specific errors when closing ssl connections
Fantix King added the comment: This should/will be fixed by GH-17975 I think - like suggested in the OpenSSL comments, the proposed change will always try to run SSL_read() before SSL_shutdown(), even after the close_notify is sent. -- nosy: +fantix ___ Python tracker <https://bugs.python.org/issue39951> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30064] BaseSelectorEventLoop.sock_{recv, sendall}() don't remove their callbacks when canceled
Change by Fantix King : -- pull_requests: +20057 pull_request: https://github.com/python/cpython/pull/20868 ___ Python tracker <https://bugs.python.org/issue30064> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30064] BaseSelectorEventLoop.sock_{recv, sendall}() don't remove their callbacks when canceled
Fantix King added the comment: and yes, updated the SO_SNDBUF too -- ___ Python tracker <https://bugs.python.org/issue30064> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30064] BaseSelectorEventLoop.sock_{recv, sendall}() don't remove their callbacks when canceled
Fantix King added the comment: OK I think I solved the problem by improving the two loops using smarter buffer sizes: # fill the buffer until sending 5 chars would block size = 8192 while size > 5: with self.assertRaises(BlockingIOError): while True: sock.send(b' ' * size) size = int(size / 2) and # receive everything that is not a space async def recv_all(): rv = b'' while True: buf = await self.loop.sock_recv(server, 8192) if not buf: return rv rv += buf.strip() This test is now running ~25x faster, and the load test crashed my laptop a few times before it hits a timeout. Last question before PR pls: given the fact that this test is to cover a fixed case when loop.sock_*() was hanging forever, should I keep the wait_for(..., timeout=10)? -- ___ Python tracker <https://bugs.python.org/issue30064> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30064] BaseSelectorEventLoop.sock_{recv, sendall}() don't remove their callbacks when canceled
Fantix King added the comment: Oh thank you for the clue, that's super helpful! Let me try locally. This fix PR was originally done to solve a hanging call in a race condition, so the test would hang forever if the fix is not working as expected. The 10 seconds wait_for() is to make sure that we don't end up with a test hanging forever. If enlarging the timeout works in some of your cases, that really inspires me on a potential cause of the issue in the test. To simulate the race condition specifically for loop.sock_sendall(), I needed a connected socket with a full send buffer so that the next sock_sendall() call would block. To achieve this, I wrote something like this: with self.assertRaises(BlockingIOError): while True: sock.send(b' ' * 5) And another loop in a subtask to consume the data: while not data: data = await self.loop.sock_recv(server, 1024) data = data.strip() It might be that it cost too much time in these loops (especially the 2nd one because the logs showed that it was blocked on calling sock_sendall()). But that's just a guess yet, let me add some more debug logs and test locally. -- ___ Python tracker <https://bugs.python.org/issue30064> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30064] BaseSelectorEventLoop.sock_{recv, sendall}() don't remove their callbacks when canceled
Fantix King added the comment: I've been testing on local VMs with Gentoo and Ubuntu, but the issue cannot be reproduced. The error log is not really revealing anything useful, other than that the send was blocked when it was supposed to be successful. As it is not constantly failing on buildbot (https://buildbot.python.org/all/#/builders/128), I don't know if it is worth it to add some more debug code to this test in master and wait for the next hang. Please kindly advise. -- ___ Python tracker <https://bugs.python.org/issue30064> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30064] BaseSelectorEventLoop.sock_{recv, sendall}() don't remove their callbacks when canceled
Fantix King added the comment: I'm checking now -- ___ Python tracker <https://bugs.python.org/issue30064> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30064] BaseSelectorEventLoop.sock_{recv, sendall}() don't remove their callbacks when canceled
Fantix King added the comment: Thanks for the comments! Added PR 20494 to properly fix/skip the test for (hopefully) all platforms. -- ___ Python tracker <https://bugs.python.org/issue30064> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30064] BaseSelectorEventLoop.sock_{recv, sendall}() don't remove their callbacks when canceled
Change by Fantix King : -- pull_requests: +19743 pull_request: https://github.com/python/cpython/pull/20494 ___ Python tracker <https://bugs.python.org/issue30064> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30064] BaseSelectorEventLoop.sock_{recv, sendall}() don't remove their callbacks when canceled
Fantix King added the comment: Not a simple one - FreeBSD is returning ECONNREFUSED immediately when trying to connect to a non-listening port on the loopback address: https://lists.freebsd.org/pipermail/freebsd-current/2005-May/049876.html Then all following connect attempts on the same socket return ECONNREFUSED regardless of whether the port is listening or not. I think I'll have to skip this test on FreeBSD. -- ___ Python tracker <https://bugs.python.org/issue30064> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30064] BaseSelectorEventLoop.sock_{recv, sendall}() don't remove their callbacks when canceled
Fantix King added the comment: Ouch ... looks like FreeBSD also needs a few more retries than a single retry. I'll test on a FreeBSD and create a PR for that. -- ___ Python tracker <https://bugs.python.org/issue30064> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30064] BaseSelectorEventLoop.sock_{recv, sendall}() don't remove their callbacks when canceled
Change by Fantix King : -- pull_requests: +19633 stage: -> patch review pull_request: https://github.com/python/cpython/pull/20369 ___ Python tracker <https://bugs.python.org/issue30064> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30064] BaseSelectorEventLoop.sock_{recv, sendall}() don't remove their callbacks when canceled
Fantix King added the comment: Following the discussion - looks like `add_reader()` will cancel the previous `handle` on the same `fd` if found, so I think it is reasonable to solve this cancellation-race issue by checking if the `handle` is cancelled as shown in the attached patch (tests in uvloop passed with this patch). WDTY? -- nosy: +fantix Added file: https://bugs.python.org/file49146/cancelled-sock-recv-race.patch ___ Python tracker <https://bugs.python.org/issue30064> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33840] connection limit on listening socket in asyncio
Change by Fantix King : -- nosy: +fantix ___ Python tracker <https://bugs.python.org/issue33840> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37179] asyncio loop.start_tls() provide support for TLS in TLS
Change by Fantix King : -- nosy: +fantix ___ Python tracker <https://bugs.python.org/issue37179> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34745] asyncio ssl memory leak
Change by Fantix King : -- pull_requests: +12348 ___ Python tracker <https://bugs.python.org/issue34745> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34745] asyncio ssl memory leak
Change by Fantix King : -- keywords: +patch pull_requests: +12343 stage: -> patch review ___ Python tracker <https://bugs.python.org/issue34745> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34745] asyncio ssl memory leak
Change by Fantix King : -- nosy: +fantix ___ Python tracker <https://bugs.python.org/issue34745> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34847] asyncio: Add PHA for TLS 1.3
New submission from Fantix King : This was raised in GH-9460 where the same post handshake authentication (PHA) was added to the ssl module. It should be added to asyncio too. This issue is to discuss the design of PHA API in asyncio, and implement it in Python 3.8. One approach is to add _SSLProtocolTransport.verify_client_post_handshake(), but an additional new transport mixin type to asyncio/transports.py would be needed (Yury). Yury also proposed another option to use get_extra_info() API to get something like an "SSLExtra" object with additional APIs. -- components: asyncio messages: 326700 nosy: asvetlov, fantix, yselivanov priority: normal severity: normal status: open title: asyncio: Add PHA for TLS 1.3 type: behavior versions: Python 3.8 ___ Python tracker <https://bugs.python.org/issue34847> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33062] ssl_renegotiate() doesn't seem to be exposed
Change by Fantix King : -- nosy: +fantix ___ Python tracker <https://bugs.python.org/issue33062> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33062] ssl_renegotiate() doesn't seem to be exposed
Change by Fantix King : -- keywords: +patch pull_requests: +8125 stage: -> patch review ___ Python tracker <https://bugs.python.org/issue33062> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23794] http package should support HTTP/2
Changes by Fantix King : -- nosy: +Fantix King ___ Python tracker <http://bugs.python.org/issue23794> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1432] Strange behavior of urlparse.urljoin
Fantix King added the comment: This issue also causes similar behavior on some libraries like mechanize which depend on urljoin -- nosy: +fantix __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1432> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
