-
-
Notifications
You must be signed in to change notification settings - Fork 31.9k
bpo-29406: asyncio SSL contexts leak sockets after calling close with certain servers #409
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
Hello, and thanks for your contribution! I'm a bot set up to make sure that the project can legally accept your contribution by verifying you have signed the PSF contributor agreement (CLA). Unfortunately we couldn't find an account corresponding to your GitHub username on bugs.python.org (b.p.o) to verify you have signed the CLA. This is necessary for legal reasons before we can look at your contribution. Please follow these steps to help rectify the issue:
Thanks again to your contribution and we look forward to looking at it! |
@1st1 PR for http://bugs.python.org/issue29406 |
I actually signed CLA before I started to contribute to tulip/asyncio |
I think you need to go to the bugs.python.org and add your GH username to your profile. |
I dont remembre account that I used when signed cla. I just re-signed it |
Maybe you used OAuth? |
my bugs.python.org details page shows "Contributor Form Received: Yes" |
Did you list your GH account name in your account on bpo? |
yes |
@brettcannon something weird is going on here with @the-knights-who-say-ni bot. @fafhrd91 Can you rebase your PR against master branch? And then add "needs backport to 3.6" and 3.5 tags. |
rebased, but I can not add labels |
Lib/asyncio/sslproto.py
Outdated
self._shutdown_timeout_handle = self._loop.call_later( | ||
self._shutdown_timeout, self._start_shutdown_timeout) | ||
|
||
def _start_shutdown_timeout(self): |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would rename this method to _on_shutdown_timeout
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
done
Lib/asyncio/sslproto.py
Outdated
self._shutdown_timeout, self._start_shutdown_timeout) | ||
|
||
def _start_shutdown_timeout(self): | ||
if self._transport is not None: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
To make the code more clear I would set self._transport = None
in _finalize
and _fatal_error
methods.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
done
added simple unit tests |
@1st1 there was nothing weird going on; you didn't remove the "CLA not signed" to retrigger the bot to check for the new CLA signing. In the end the synchronizing of the PR triggered the bot again and picked up on the signing. |
Lib/asyncio/sslproto.py
Outdated
|
||
def _finalize(self): | ||
if self._transport is not None: | ||
self._transport.close() | ||
self._transport = None | ||
if self._shutdown_timeout_handle is not None: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
little nit: I'd add a newline before this if
.
@@ -412,7 +413,7 @@ class SSLProtocol(protocols.Protocol): | |||
|
|||
def __init__(self, loop, app_protocol, sslcontext, waiter, | |||
server_side=False, server_hostname=None, | |||
call_connection_made=True): | |||
call_connection_made=True, shutdown_timeout=5.0): |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why is it 5 seconds? Is this some timeout value defined in some SSL RFC?
@fafhrd91 ping |
5 seconds just some number |
You may want to see #981 |
@fafhrd91 I honestly don't know. In my case (with the server/client described in my PR), |
@fafhrd91 Could you please rebase this PR on the most recent master? I'll merge it then. |
@1st1 done |
wait |
@1st1 restored |
Can you add a NEWS entry? |
added |
unittests don't seem to pass :( |
@@ -679,12 +692,18 @@ def _fatal_error(self, exc, message='Fatal error on transport'): | |||
}) | |||
if self._transport: | |||
self._transport._force_close(exc) | |||
self._transport = None |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should we also cleanup _shutdown_timeout_handle
here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should fatal_error
just call finalize
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think that makes sense.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
added cleanup code for _shutdown_timeout_handle
, it is possible to get here while handle still active
…e with certain servers (GH-409) (#2062) * bpo-29406: asyncio SSL contexts leak sockets after calling close with certain servers (#409) (cherry picked from commit a608d2d) * [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 a608d2d)
…e with certain servers (GH-409) (#2063) * bpo-29406: asyncio SSL contexts leak sockets after calling close with certain servers (#409) (cherry picked from commit a608d2d) * [3.5] 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 a608d2d)
Bumps [aiohttp](https://github.com/aio-libs/aiohttp) from 3.6.2 to 3.7.2. - [Release notes](https://github.com/aio-libs/aiohttp/releases) - [Changelog](https://github.com/aio-libs/aiohttp/blob/master/CHANGES.rst) - [Commits](aio-libs/aiohttp@v3.6.2...v3.7.2) Signed-off-by: dependabot-preview[bot] <[email protected]> Co-authored-by: dependabot-preview[bot] <27856297+dependabot-preview[bot]@users.noreply.github.com>
Some servers does not complete ssl shutdown procedure, which cause socket leak on asyncio side.