I've written an HTTP daemon (like Apache) with Boost that takes https connections with openssl. Everything is working fine, except that it's leaking memory. Valgrind shows the leak is always in the openssl functions, and the backtrace shows it always starts inside boosts architecture. The backtraces are something like (this is heavily cleaned up since they're huge): CRYPTO_malloc openssl_stream_service::ssl_wrap openssl_operation::async_read_handler boost_asio_handler_invoke_helpers::invoke strand_service::dispatch asio_handler_invoke task_io_service::do_one io_service::run thread_proxy start_thread clone In my code I have a single 'server' class, I have a single instance of boost::asio::ssl::context(_io_service,boost::asio::ssl::context::sslv23) which I setup one time in my server's constructor (setting use_certificate_chain_file, etc). I also have an boost::asio::io_service and a boost::asio::ip::tcp::acceptor. An instance of my Connection class is created for each inbound connection, and it has a boost ssl_socket, which gets the io_service and context (by reference). Naturally lots and lots of other code too, and it's all working. My Connection objects are properly deleted when the connection is done, and so is the boost ssl_socket. And I call ssl_socket::shutdown(ip::tcp::socket::shutdown_both, ec) before deleting the socket. But it seems that's not enough to free all the memory. Valgrind shows there are no stray copies of any of my objects or of any boost objects that I created. Just all these openssl calls that originate within the boost framework. What's very strange is that the number of allocations leaked doesn't correspond to the number of connections. If my app starts and exits with no connections, there are only some leaks in static constructors, which, from what I read, is a known bug in openssl. But after there is 1 connection, there are about 6 new leaks similar to that stack trace above. After there are 10 connections, there are 16 leaks. But after 40 connections, there are only 18 leaks. So the leaks grows gradually, but over time it does keep growing until my app runs out of memory. Anybody know what cleanup functions I might not be calling to free up the memory? Thanks.