Skip to content
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

We've really done it now - every connection will live forever in memory #136

Open
TechnikEmpire opened this issue Oct 17, 2017 · 4 comments
Assignees
Labels

Comments

@TechnikEmpire
Copy link
Owner

At some unknown point in history, our use enable_shared_from_this has ended up causing every connection to get pinned in memory forever. Massive leak, unsure how this snuck by unnoticed for what appears to be some time.

@TechnikEmpire TechnikEmpire self-assigned this Oct 17, 2017
@TechnikEmpire
Copy link
Owner Author

Even more interesting, a single destructor for ~TlsCapableHttpBridge() will get call on application exit, but not all the rest.

@TechnikEmpire
Copy link
Owner Author

I believe the cause of this is the use of lambda's for the async asio functions, where we use a shared_ptr self reference and pass it to the lambda via the capture list. This smells like the kind of situation that would pin a shared_ptr forever because you're defining it inside of a member function and capturing inside of another member function.

@TechnikEmpire
Copy link
Owner Author

TechnikEmpire commented Oct 17, 2017

Methinks the best solution here is to entirely eliminate shared_from_this and just have the acceptors keep instances to clients, and make them drop instances when a client flags itself as finito. This will avoid the problem both now and forever.

@TechnikEmpire
Copy link
Owner Author

Sigh, even if we do the above change, the asio reactor will hold on to callback references for an indeterminate period of time. If we allow this to expire while the reactor is still holding those callbacks, then we'll get a hard crash because the object is gone when the callback is finally invoked.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

1 participant