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

[Loïc Hoguin]

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.
>>
>


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