<div dir="ltr">We are aware of this problem and I think there is a fix to R16B03. I don't see it on maint on GitHub yet.<div><br></div><div>The runtime forces the port to unlink during port_close in some cases which causes this problem.</div>
<div><br></div><div>// Björn-Egil</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">2013/12/6 Brandon Clark <span dir="ltr"><<a href="mailto:a.brandon.clark@gmail.com" target="_blank">a.brandon.clark@gmail.com</a>></span><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Greetings!<div><br></div><div>I have an application where, once in a while, processes appear to hang in prim_inet:close_port/1.  I'm not sure what to do with that.</div>
<div><br></div><div>The application uses R16B02.</div>
<div><br></div><div>Here's a sample of the process info for a "stuck" process:</div><div><br></div><div><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><div><font face="courier new, monospace">[{current_stacktrace,[{prim_inet,close_port,1,[]},</font></div>

<div><font face="courier new, monospace">                        {inet,tcp_close,1,[{file,"inet.erl"},{line,1422}]},</font></div><div><font face="courier new, monospace">                        {proxy_worker,disconnect_endpoint,1,</font></div>

<div><font face="courier new, monospace">                                      [{file,"src/proxy_worker.erl"},{line,1082}]},</font></div><div><font face="courier new, monospace">                        {proxy_worker,process_chunked_reply,1,</font></div>

<div><font face="courier new, monospace">                                      [{file,"src/proxy_worker.erl"},{line,496}]},</font></div><div><font face="courier new, monospace">                        {proxy_worker,process_request,2,</font></div>

<div><font face="courier new, monospace">                                      [{file,"src/proxy_worker.erl"},{line,100}]},</font></div><div><font face="courier new, monospace">                        {proxy_worker,work_request,2,</font></div>

<div><font face="courier new, monospace">                                      [{file,"src/proxy_worker.erl"},{line,87}]},</font></div><div><font face="courier new, monospace">                        {pool_worker,handle_cast,2,</font></div>

<div><font face="courier new, monospace">                                     [{file,"src/pool_worker.erl"},{line,73}]},</font></div><div><font face="courier new, monospace">                        {gen_server,handle_msg,5,</font></div>

<div><font face="courier new, monospace">                                    [{file,"gen_server.erl"},{line,604}]}]},</font></div><div><font face="courier new, monospace">   {current_function,{prim_inet,close_port,1}},</font></div>

<div><font face="courier new, monospace">   {initial_call,{proc_lib,init_p,5}},</font></div><div><font face="courier new, monospace">   {status,waiting},</font></div><div><font face="courier new, monospace">   {message_queue_len,1},</font></div>

<div><font face="courier new, monospace">   {messages,[{tcp_closed,#Port<<a href="tel:9492.545567" value="+19492545567" target="_blank">9492.545567</a>>}]},</font></div><div><font face="courier new, monospace">   {links,[<<a href="tel:9492.10266.0" value="+19492102660" target="_blank">9492.10266.0</a>>]},</font></div>

<div><font face="courier new, monospace">   {dictionary,[{'$ancestors',[<<a href="tel:9492.10266.0" value="+19492102660" target="_blank">9492.10266.0</a>>,<<a href="tel:9492.10263.0" value="+19492102630" target="_blank">9492.10263.0</a>>,</font></div>

<div><font face="courier new, monospace">                               cellophane_sup,<9492.114.0>]},</font></div><div><font face="courier new, monospace">                {'$initial_call',{pool_worker,init,1}}]},</font></div>

<div><font face="courier new, monospace">   {trap_exit,true},</font></div><div><font face="courier new, monospace">   {error_handler,error_handler},</font></div><div><font face="courier new, monospace">   {priority,normal},</font></div>

<div><font face="courier new, monospace">   {group_leader,<9492.113.0>},</font></div><div><font face="courier new, monospace">   {total_heap_size,2586},</font></div><div><font face="courier new, monospace">   {heap_size,2586},</font></div>

<div><font face="courier new, monospace">   {stack_size,44},</font></div><div><font face="courier new, monospace">   {reductions,4490210},</font></div><div><font face="courier new, monospace">   {garbage_collection,[{min_bin_vheap_size,46422},</font></div>

<div><font face="courier new, monospace">                        {min_heap_size,233},</font></div><div><font face="courier new, monospace">                        {fullsweep_after,0},</font></div><div><font face="courier new, monospace">                        {minor_gcs,0}]},</font></div>

<div><font face="courier new, monospace">   {suspending,[]}]}]</font></div></blockquote><font face="courier new, monospace"><br></font></div><div><font face="arial, helvetica, sans-serif">Apparently, this condition occurs -- intermittently -- when the client (the process described above) and the server (a different app and platform) decide to close their socket connection at about the same time.  Notice the tcp_closed message in the inbox.</font></div>

<div><font face="arial, helvetica, sans-serif"><br></font></div><div><font face="arial, helvetica, sans-serif">The socket in question is in {active, once} mode.</font></div><div><font face="arial, helvetica, sans-serif"><br>

</font></div><div><font face="arial, helvetica, sans-serif">The {status,waiting} and {trap_exit, true} suggest to me that the process is stuck in the receive at line 210 of prim_inet:</font></div><div><font face="arial, helvetica, sans-serif"><br>

</font></div><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><div><font face="arial, helvetica, sans-serif"> </font><font face="courier new, monospace">188 close_port(S) -></font></div><div><font face="courier new, monospace"> 189     case erlang:process_info(self(), trap_exit) of</font></div>

<div><font face="courier new, monospace"> 190         {trap_exit,true} -></font></div><div><font face="courier new, monospace"> 191             %% Ensure exit message and consume it</font></div><div><font face="courier new, monospace"> 192             link(S),</font></div>

<div><font face="courier new, monospace"> 193             %% This is still not a perfect solution.</font></div><div><font face="courier new, monospace"> 194             %%</font></div><div><font face="courier new, monospace"> 195             %% The problem is to close the port and consume any exit</font></div>

<div><font face="courier new, monospace"> 196             %% message while not knowing if this process traps exit</font></div><div><font face="courier new, monospace"> 197             %% nor if this process has a link to the port. Here we</font></div>

<div><font face="courier new, monospace"> 198             %% just knows that this process traps exit.</font></div><div><font face="courier new, monospace"> 199             %%</font></div><div><font face="courier new, monospace"> 200             %% If we right here get killed for some reason that exit</font></div>

<div><font face="courier new, monospace"> 201             %% signal will propagate to the port and onwards to anyone</font></div><div><font face="courier new, monospace"> 202             %% that is linked to the port. E.g when we close a socket</font></div>

<div><font face="courier new, monospace"> 203             %% that is not ours.</font></div><div><font face="courier new, monospace"> 204             %%</font></div><div><font face="courier new, monospace"> 205             %% The problem can be solved with lists:member on our link</font></div>

<div><font face="courier new, monospace"> 206             %% list but we deem that as potentially too expensive. We</font></div><div><font face="courier new, monospace"> 207             %% need an is_linked/1 function or guard, or we need</font></div>

<div><font face="courier new, monospace"> 208             %% a port_close function that can atomically unlink...</font></div><div><font face="courier new, monospace"> 209             catch erlang:port_close(S),</font></div>

<div><font face="courier new, monospace" style="background-color:rgb(255,255,0)"> 210             receive {'EXIT',S,_} -> ok end;</font></div><div><font face="courier new, monospace"> 211         {trap_exit,false} -></font></div>

<div><font face="courier new, monospace"> 212             catch erlang:port_close(S),</font></div><div><font face="courier new, monospace"> 213             ok</font></div><div><font face="courier new, monospace"> 214     end.</font></div>

</blockquote><font face="arial, helvetica, sans-serif"><br></font><div><font face="arial, helvetica, sans-serif">But now I'm speculating.  I'm in over my head, here.</font></div><div><font face="arial, helvetica, sans-serif"><br>

</font></div><div><font face="arial, helvetica, sans-serif">Any suggestions on how to clear up these stuck processes would be greatly appreciated!</font></div><div><div><img></div><span class="HOEnZb"><font color="#888888">
</font></span></div><span class="HOEnZb"><font color="#888888"><span><font color="#888888"><div style="font-family:arial,sans-serif;font-size:13px"><font face="arial, helvetica, sans-serif"><br></font></div><div style="font-family:arial,sans-serif;font-size:13px">
<font face="arial, helvetica, sans-serif">~BC</font></div>
<div><font face="arial, helvetica, sans-serif"><br></font></div></font></span></font></span></div>
<br>_______________________________________________<br>
erlang-questions mailing list<br>
<a href="mailto:erlang-questions@erlang.org">erlang-questions@erlang.org</a><br>
<a href="http://erlang.org/mailman/listinfo/erlang-questions" target="_blank">http://erlang.org/mailman/listinfo/erlang-questions</a><br>
<br></blockquote></div><br></div>