Memory Leak on GET request.

Bug #1208537 reported by maker
10
This bug affects 2 people
Affects Status Importance Assigned to Milestone
pyOpenSSL
New
Undecided
Unassigned

Bug Description

As in subject, pyopenssl seems affected by a memory leak whenever destroying a connection. Attaching example file.

Testing with::
[maker@tumbolandia t2w]$ for i in {1..50}; do curl --insecure https://localhost:4443/

Gives:
240017
240159
240300
240441
240582
240723
.....
243293
243434
243575
243716
243857
243998
244139

As you can tell, there's a delta of 141 objects between each couple of prints.

Tags: leak
Revision history for this message
maker (maker-3) wrote :
Revision history for this message
maker (maker-3) wrote :

For what I have been able to investigate in the last few days, thanks to the help of dickinsm, I've found that there is no real leak, but probably just a circular dependency. In fact, a simple gc.collect() inside the get callback is going to behave the same as a normal tcp connection.

I'm attaching a small script that shows which objects' reference has been increased between two requests, and three log files:
ssl.log - is the log generated by running the file as-it-is:
              (t2w)[maker@tumbolandia t2w]$ python leak.4.py > ssl.log
             [maker@tumbolandia t2w]$ for i in {1..1000}; do curl --insecure https://localhost:4443/; done

tcp.log - has been created using listenTCP instead of listenSSL, and run with:
             (t2w)[maker@tumbolandia t2w]$ python leak.4.py > tcp.log
             [maker@tumbolandia t2w]$ for i in {1..1000}; do curl http://localhost:4443/; done

collecting.log - is the log generated by simply incommenting the gc.collect() in line 26.
             (t2w)[maker@tumbolandia t2w]$ python leak.4.py > collecting.log
             [maker@tumbolandia t2w]$ for i in {1..1000}; do curl --insecure https://localhost:4443/; done

So my wonder now is, why delayedcall objects are kept this long in memory? Seems like contains the logs for the current request, accessible through Site._logDateTimeCall.

Probably we can get rid of the circular dependency between BIOProtocol and HTTPChannel setting the ssl attributes to None on the lostConnection method of the ssl factory; but this would concern twisted itself. Shall I open another issue there?

Revision history for this message
maker (maker-3) wrote :
Revision history for this message
maker (maker-3) wrote :
Revision history for this message
maker (maker-3) wrote :
Revision history for this message
maker (maker-3) wrote :
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.