[erlang-bugs] prim_inet:close/1 race condition

[Fred Hebert]

I've had the same problem in my lhttpc fork, and after some concerted 
work with a few users of the fork at OpenX, we made the following fix in 
the lhttpc wrapper 
(https://github.com/ferd/lhttpc/blob/master/src/lhttpc_sock.erl#L172):

Flag = process_flag(trap_exit, true),
Res = gen_tcp:close(Socket),
receive
{'EXIT',_Pid,timeout} -> exit(timeout)
after 0 ->
process_flag(trap_exit, Flag),
Res
end

We're able to do it because we expect, 99.999% of the time that the race 
condition will happen with a specific exit message we chose ourselves in 
that given context (we control the process where this happens 100%). I 
can't think of a universally good way to fix it in Erlang itself, where 
you'd risk eating up messages you're not supposed to handle, though.

On 12-10-11 5:06 PM, Dmitry Belyaev wrote:
> Some days ago we found that we have thousands of leaked sockets in our 
> project.
>
> These sockets were ports with state like this:
> [{name,"tcp_inet"},
>  {links,[]},
>  {connected,<0.54.0>},...]
>
> We made investigation and found the cause of the leaks.
>
> We have inets option {exit_on_close, false} to read statistics from 
> the socket after it was closed by the peer. Process that controls the 
> socket does not trap_exit and is linked with some another process.
> At the end of connection controller calls gen_tcp:close/1 and 
> sometimes the linked process dies at that the same moment. We found 
> out that the gen_tcp:close/1 calls prim_inet:close/1, the first action 
> of which is unlink from controlling process. So, when controller is 
> unlinked from the port and is killed by the signal, port stays in the 
> system because of exit_on_close feature.
>
> I've made a module that sometimes may reveal the problem. 
> https://gist.github.com/3875485
> On my system I half of dozen calls to close_bug:start(1000) does find 
> such leaked ports.
> I haven't found the right solution for the problem yet, so no patches 
> at the moment.
>
> Thank you for your attention.
>
> -- 
> Dmitry Belyaev
>
>
> _______________________________________________
> erlang-bugs mailing list
> erlang-bugs@REDACTED
> http://erlang.org/mailman/listinfo/erlang-bugs

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-bugs/attachments/20121011/8520c87f/attachment.htm>