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

[Loïc Hoguin]

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