[erlang-questions] Erlang crash gen_tcp related (probably only under Windows)

[Michael Regen]

Hi,

I got a series of troubles with gen_tcp all eventually resulting in crashes.
I tested this under Windows XP and with R12B-3 as well as R12B-4. Under
Linux it seems to work but I am not perfectly sure since the crash happens
sporadically and seems to be timing related.

The two problems below lead me to a couple of questions:
a) What is the real cause? Is it the socket error enfile? Do both problems
have the same root cause?
b) Is there a bug in Erlang? I guess this should not lead to a crash.
c) How do you avoid this problem on systems you do not control yourself?


Problem #1:
###########

Just compile the following code and run it with sasl enabled and the
following command:
  tcp_test:test(1000).
and - yes - without anything listening on port 2222. And sometimes you have
to try two times!

-------------------------- start: tcp_test.erl --------------------------
-module(tcp_test).

-export([test/1, test_con/0]).

-define(DEF_PORT, 2222).
-define(DEF_IP, {127,0,0,1}).

test(0) -> ok;
test(HowManyProcs) ->
  spawn(?MODULE, test_con, []),
  test(HowManyProcs-1).

test_con() ->
  {ok,S} = gen_tcp:connect(?DEF_IP, ?DEF_PORT,[]),
  gen_tcp:send(S,<<0,5,65,66,67,68,69>>),
  receive
    {tcp_closed, _Socket} -> ok;
    _Msg -> gen_tcp:close(S)
  after 500 ->
    gen_tcp:close(S)
  end.
-------------------------- end: tcp_test.erl --------------------------

It just spawns a bunch of processes all trying to connect to a currently
closed port and sending some garbage there. This is what happens:

-------------------------- start: log tcp_test.erl
--------------------------
=ERROR REPORT==== 12-Sep-2008::15:28:47 ===
Error in process <0.41.0> with exit value:
{{badmatch,{error,econnrefused}},[{tcp_test,test_con,0}]}

[... a couple of them but usually between 1 and 20.]

=ERROR REPORT==== 12-Sep-2008::15:28:47 ===
Error in process <0.103.0> with exit value:
{{badmatch,{error,econnrefused}},[{tcp_test,test_con,0}]}


Crash dump was written to: erl_crash.dump
Inconsistent, why isnt io reported?

Abnormal termination
-------------------------- end: log tcp_test.erl --------------------------

It might have something to do with the socket error enfile 'file table
overflow'  but I guess it should not simply crash the emulator!?
Searching google for 'Inconsistent, why isnt io reported?' just gives one
hit to Erlang's source code.
I can provide the crash dump if needed. Just did not want to spam the whole
list with big attachments.
Spawning only 500 processes (tcp_test:test(500).) usually leads to a crash,
spawning only 200 seems to work.


Problem #2:
###########

Now let's try the same with a server answering to port 2222: Just take the
code from the trapexit tutorial 'Building a Non-blocking TCP server using
OTP principles'
http://trapexit.org/Building_a_Non-blocking_TCP_server_using_OTP_principles
Start it first and then our test module in a different erlang node as
described above. Now, usually the client survives (have seen crashes as
well!) and the server crashes in a similar way. Sometimes it survives and in
very rare cases you will see the following logs in the erlang server
instance:

-------------------------- start: log server --------------------------
=ERROR REPORT==== 12-Sep-2008::12:58:56 ===
File operation error: system_limit. Function: get_cwd. Process: code_server.

=ERROR REPORT==== 12-Sep-2008::12:58:56 ===
Error in async accept: {async_accept,"file table overflow"}.

=ERROR REPORT==== 12-Sep-2008::12:58:56 ===
** Generic server tcp_listener terminating
** Last message in was {inet_async,#Port<0.109>,1019,{ok,#Port<0.2141>}}
** When Server state == {state,#Port<0.109>,1019,tcp_echo_fsm}
** Reason for termination ==
** {async_accept,"file table overflow"}

[...]
-------------------------- end: log server --------------------------

Can anyone help? Thank you!

Regards,
Michael
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20080912/38a57467/attachment.htm>