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

[Ingela Anderton Andin]

Hi!

Well as you have a server  increase the timeout in ssl_accept/[2,3], you 
do not want
it to expire unless there is a network failure.

Regards Ingela Erlang/OTP team - Ericsson AB

Loïc Hoguin wrote:
> Alright.
>
> What should I do for a temporary fix to make sure this is the right 
> issue?
>
> On 11/07/2012 04:12 PM, Ingela Anderton Andin wrote:
>> Hi!
>>
>> The problem is that "call-timeouts"  in gen_server/fsm suck, as they are
>> purly client side. The {ref, connected} is a gen:fsm-reply that should
>> have been received by the ssl connect code.  Like the recv problem on
>> erlang-questions this is solved by making the timer server side,  it
>> could be argued some of these timeouts in ssl API are not needed, but
>> they are legacy...  We will fix it.  After some investigation I think
>> the "best" solution to your other problem will be call gen_tcp:recv/3 in
>> the workaround. We will also clean up the logic in terminate.
>>
>> Regards Ingela Erlang/OTP team - Ericsson AB
>>
>>
>> Loïc Hoguin wrote:
>>> On 11/01/2012 12:38 PM, Loïc Hoguin wrote:
>>>> * 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.
>>>
>>> In this particular case, here's what we got:
>>>
>>> [{current_function,{gen_fsm,loop,7}},
>>>  {initial_call,{proc_lib,init_p,5}},
>>>  {status,waiting},
>>>  {message_queue_len,0},
>>>  {messages,[]},
>>>  {links,[<0.897.0>,#Port<0.264729349>]},
>>>  {dictionary,[{ssl_manager,ssl_manager},
>>>               {'$ancestors',[ssl_connection_sup,ssl_sup,<0.894.0>]},
>>>               {'$initial_call',{ssl_connection,init,1}}]},
>>>  {trap_exit,false},
>>>  {error_handler,error_handler},
>>>  {priority,normal},
>>>  {group_leader,<0.893.0>},
>>>  {total_heap_size,8362},
>>>  {heap_size,4181},
>>>  {stack_size,10},
>>>  {reductions,7029},
>>>  {garbage_collection,[{min_bin_vheap_size,46368},
>>>                       {min_heap_size,233},
>>>                       {fullsweep_after,10},
>>>                       {minor_gcs,10}]},
>>>  {suspending,[]}]
>>>
>>> Looking further, I notice something weird.
>>>
>>> > erlang:process_info(Pid, monitors).
>>> {monitors,[{process,<0.1055.0>}]}
>>>
>>> This is a very old pid.
>>>
>>> > erlang:process_info(OldPid).
>>> [{current_function,{prim_inet,accept0,2}},
>>>  {initial_call,{cowboy_acceptor,acceptor,7}},
>>>  {status,waiting},
>>>  {message_queue_len,1602},
>>>  {messages,[{#Ref<0.0.19.196440>,connected},
>>>             {#Ref<0.0.21.74727>,connected},
>>>             {#Ref<0.0.28.93234>,connected},
>>>             {#Ref<0.0.64.192190>,connected},
>>>             {#Ref<0.0.167.184831>,connected},
>>>             {#Ref<0.0.208.24369>,connected},
>>>             {#Ref<0.0.282.59352>,connected},
>>>             {#Ref<0.0.340.181599>,connected},
>>>             {#Ref<0.0.341.57338>,connected},
>>>             {#Ref<0.0.427.15661>,connected},
>>>             {#Ref<0.0.430.8560>,connected},
>>>             {#Ref<0.0.439.40688>,connected},
>>>             {#Ref<0.0.439.214050>,connected},
>>>             {#Ref<0.0.440.206978>,connected},
>>>             {#Ref<0.0.466.173049>,connected},
>>>             {#Ref<0.0.497.35749>,connected},
>>>             {#Ref<0.0.514.36774>,connected},
>>>             {#Ref<0.0.514.109971>,connected},
>>>             {#Ref<0.0.541.246233>,connected},
>>>             {#Ref<0.0.544.168339>,connected},
>>>             {#Ref<0.0.584.43294>,...},
>>>             {...}|...]},
>>>  {links,[<0.1028.0>]},
>>>  {dictionary,[]},
>>>  {trap_exit,false},
>>>  {error_handler,error_handler},
>>>  {priority,normal},
>>>  {group_leader,<0.868.0>},
>>>  {total_heap_size,32838},
>>>  {heap_size,4181},
>>>  {stack_size,22},
>>>  {reductions,219876367},
>>>  {garbage_collection,[{min_bin_vheap_size,46368},
>>>                       {min_heap_size,233},
>>>                       {fullsweep_after,10},
>>>                       {minor_gcs,1}]},
>>>  {suspending,[]}]
>>>
>>> So this is the acceptor process. It doesn't make sense though, why
>>> would the ssl process still monitor the acceptor? The acceptor code is
>>> equivalent to this:
>>>
>>> {ok, Socket} = ssl:transport_accept(ListenSocket, 2000),
>>> ok = ssl:ssl_accept(Socket, 2000),
>>> {ok, Pid} = supervisor:start_child(SupPid, Args),
>>> Transport:controlling_process(Socket, Pid),
>>> %% ...
>>>
>>> I'm also not sure what {#Ref<0.0.19.196440>,connected} is. Are they
>>> supposed to receive this?
>>>
>>> Any pointer as to where to look next would help.
>>>
>>> Thanks.
>>>
>>
>
>