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

[Ingela Anderton Andin]

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