[erlang-bugs] concurrent ssl:transport_accept() trashes options

Daniel Goertzen <>
Wed Dec 5 05:25:42 CET 2012

I am working with an ssl acceptor pool (10 acceptors) and am using the
{packet,4} option.  The first incoming connection works fine, however the
second connection ends up using {packet,0}.

Short version: ssl:transport_accept() is just plain thread-unsafe with
respect to ListenSocket.

Long version:
In ssl:transport_accept(), options on the underlying listen socket are
backed up and then replaced with internal_inet_values() as shown below.
 When the underlying transport accept() returns, the backup up options are
put back into the listen socket and also go on to form options in an ssl

The problem is that a second transport_accept() call will backup
*internal_inet_values* , and those incorrect values will be passed onto the
ssl process.

Thats what it looks like anyway; I haven't traced everything out in detail.
 My work around for now is to set my acceptor pool to size 1 (can you still
call that a pool? ;)


>From ssl.erl:

transport_accept(#sslsocket{pid = {ListenSocket, #config{cb=CbInfo,
ssl=SslOpts}}}, Timeout) ->

    %% The setopt could have been invoked on the listen socket
    %% and options should be inherited.
    EmOptions = emulated_options(),
    {ok, InetValues} = inet:getopts(ListenSocket, EmOptions),
    ok = inet:setopts(ListenSocket, internal_inet_values()),
    {CbModule,_,_, _} = CbInfo,
    case CbModule:accept(ListenSocket, Timeout) of
{ok, Socket} ->
    ok = inet:setopts(ListenSocket, InetValues),
    {ok, Port} = inet:port(Socket),
    ConnArgs = [server, "localhost", Port, Socket,
{SslOpts, socket_options(InetValues)}, self(), CbInfo],
    case ssl_connection_sup:start_child(ConnArgs) of
{ok, Pid} ->
    ssl_connection:socket_control(Socket, Pid, CbModule);
{error, Reason} ->
    {error, Reason}
{error, Reason} ->
    {error, Reason}

emulated_options() ->
    [mode, packet, active, header, packet_size].

internal_inet_values() ->
    [{packet_size,0},{packet, 0},{header, 0},{active, false},{mode,binary}].
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-bugs/attachments/20121204/9f8ac8cd/attachment.html>

More information about the erlang-bugs mailing list