[erlang-bugs] [erlang-questions] Process/FD leak in SSL R15B01

[Loïc Hoguin]

On 10/30/2012 05:50 PM, Ingela Anderton Andin wrote:
> Hi!
>
> Loïc Hoguin wrote:
>> I don't understand why there's no timeout though. Wouldn't it make
>> sense to have a small timeout to avoid this and any related problem
>> entirely?
>>
>
> Well yes and no ;) ssl:close should conceptually not fail so you should
> not need a timeout. The problem seems to be that be that the cleaning
> up code sometimes could cause a unforeseen hanging problem, as in the
> rabbitmq case. Although in your case it seems that the problem is
> something else, at least some of the times. Currently I am thinking that
> maybe the close function is incorrectly implemented and that it should
> utilize supervisor:terminate_child so that the OTP-supervisor will
> kill the process if it hangs in terminate. (It has a timeout) I will
> work on making sush a patch. I suppose in the meantime you could
> implement a timeout to ssl-close and verify that this timeout would
> solve your problem. As then my suggested way should solve it too just
> more OTPish and without the need of extending the API.

OK so perhaps I have done something wrong before when testing.

Today I can most certainly say that:

* This problem occurs *only* when ssl_connection processes receive 
'DOWN' in handle_info. The sockets for this problem stay in FIN2.

* Removing the call for recv/2 itself removes this problem entirely.

* There is another problem where processes get stuck elsewhere, which 
I'm going to try to investigate. Note that the sockets for this problem 
stay in ESTABLISHED.

-- 
Loïc Hoguin
Erlang Cowboy
Nine Nines
http://ninenines.eu