-
-
Notifications
You must be signed in to change notification settings - Fork 31.9k
bpo-29870: ssl socket leak #981
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
@misg, thanks for your PR! By analyzing the history of the files in this pull request, we identified @1st1, @fafhrd91 and @serhiy-storchaka to be potential reviewers. |
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 our records indicate you have not signed the CLA. For legal reasons we need you to sign this before we can look at your contribution. Please follow the steps outlined in the CPython devguide to rectify this issue. Thanks again to your contribution and we look forward to looking at it! |
(I just signed the CLA today btw) |
I digged a little more by putting a I think that clearly shows that the above reference cycle hides some reference cycles between these C objects, leading to these leaks. Honestly, I don't know if my patch is sufficient to patch these leaks. I believe this cycle reference is introduced by the use of a callback after ssl handshake and before ssl shutdown (see attributes |
Note: there is no difference between Python 3.6 and 3.5.2 regarding this issue |
Thanks for the PR and research, @misg! Will merge this in 3.6.2. |
@misg I'll merge this PR now, but please submit another PR with some kind of test to avoid regressions in the future. |
Thanks for your review and merge, @1st1! You're right, I forgot to include some kind of test, I'm going to fix that. |
Does this still need backporting? |
If not please remove the label. |
I'm using
Python 3.6
andaiohttp 2.0.5
.Given this server:
and this client (that basically sends
get
requests to the above server):I have been able to reproduce the issue. In fact, every 6-7
get
requests, I got aVariation: 0.25
printed on my screen that indicates my client uses 0.25 more MB of memory (it just grows indefinitely, I tested it with 10000 requests).Using ipdb and objgraph led me to this graph where you can clearly see that there are some circular references between
SSLProtocol
and_SSLPipe
objects:I know that since PEP 442 it shouldn't be a problem anymore, the python garbage collector doesn't care about the cycle and collect them anyway. But the interesting fact is that breaking this cycle (see my commit) actually fixes the memory leak in my client (no more
Variation: 0.25
, just alwaysVariation: 0.0
). My hypothesis is that circular references betweenSSLProtocol
and_SSLPipe
actually hide some circular references between some C objects (that define sometp_dealloc
slots), that lead to these memory leaks.