[erlang-questions] A question on EINVAL in active-mode TCP

James Fish james@REDACTED
Thu Jun 30 16:58:41 CEST 2016


I believe the race condition occurring is that the gen_tcp port will exit
after it sends a {tcp_closed, Socket} message when in active mode. When
calling a gen_tcp function the module for the Socket (Erlang port) is
looked up using a BIF (for ipv4 and ipv6 are different modules internally).
If the port doesn't exist when the lookup occurs then you get {error,
closed}. Otherwise the module is returned and that module is used to
communicate with Socket (Erlang port). It is possible for the port to exit
in between the lookup of the module and the actual call. This situation
leads to {error, einval} as that is the error returned by the lower level
inet port calls. You can see this occur when using inet:setopts/2 as the
module isn't looked up (IIRC) and {error, einval} is always returned on a
"dead" Erlang port.

It is possible to stop the gen_tcp socket exiting on {tcp_closed, Socket}
by using the {exit_on_close, false} inet option. However then you will need
to call gen_tcp:close(Socket) if the controlling process does not exit when
the connection closes.

On 30 June 2016 at 14:58, Jesper Louis Andersen <
jesper.louis.andersen@REDACTED> wrote:

>
> On Thu, Jun 30, 2016 at 10:58 AM, Magnus Ottenklinger <
> magnus.ottenklinger@REDACTED> wrote:
>
>> We stumbled over a peculiarity in the usage of ports in a TCP connection
>> (active mode). Specifically, we encountered `einval` when writing to a
>> socket which was closed just before. Our expectation was that the resulting
>> error should be `{error,closed}`. The following module reproduces this on
>> my machine (OTP 19.0). I ran the test module with `erlc test.erl && erl -s
>> test run -noshell` as well as with `erl -smp disable +A 0 -s test run
>> -noshell`. Both executions triggered `einval`.
>
>
> Knowing what operating system it is could help. Low level TCP isn't
> entirely the same thing in its response codes, even though POSIX exists.
> There are some things down here which are up to "interpretation" for some
> levels of interpretation.
>
> It does, from your failing program, look like it is a race however. The
> question is if anything can be done about it.
>
>
>
> --
> J.
>
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20160630/906e2d6e/attachment.htm>


More information about the erlang-questions mailing list