[erlang-bugs] ssl memory leak

Daniel Barney dan353hehe@REDACTED
Wed Jan 9 18:47:45 CET 2013


Hey guys so this is what i'm seeing. I'm trying to debug this issue
and have found a few things but I am still missing something.

I'm upgrading a tcp connection so an ssl connection manually. mostly
because i need to serve different certificates, and starting up
another listener to listen on the same port but a different ip address
is just a little cumbersome. So i have one listener that upgrades a
connection based on which ip the client connects to. Right now I have
200+ ip addresses on the machine that have certs associated with them.

This is how i am doing it:

ssl:ssl_accept(Socket,[{active,false},{verify, verify_none}] ++ Certs)

where Socket is a gen_tcp socket. and Certs is a proplist containing
the paths to the certs.

The problem that I am seeing is two ets tables grow linearly as the
system accepts encrypted requests. the tables that grow are the
'ssl_otp_cacertificate_db' and 'ssl_otp_ca_file_ref'. both tables are
started and managed by the ssl_manager process.

I have found one memory leak submitted a patch to fix it, but it has
never shown up on the erlang-patches list. I will include it here

this is the patch that fixes around 90% of the leaks that i saw:

https://gist.github.com/4495139

i put it in a gist, because gmail will mangle it. What the patch does
is it sends the cleaning message to the ssl_manager process, instead
of the ssl_connection process that is requesting the cleaning.

The patch fixes a lot of the leaking. Before applying the patch every
single time a tcp connection was upgraded, the certs would be leaked
and never removed from the 'ssl_otp_cacertificate_db' table. After the
patch, almost all of them are removed, but something is happening that
i can't see, and it is still not removing the certificates from the
table.

This normally grinds my servers to a halt after 2 days, which means
right now I have to log in and restart them every day. So i would
really appreciate any help to track this issue down.

looking for some help,
Daniel



More information about the erlang-bugs mailing list