[#8815] Segfault in libc strlen, via rb_str_new2 — "Sean E. Russell" <ser@...>

Howdy,

12 messages 2006/09/09
[#8817] Re: Segfault in libc strlen, via rb_str_new2 — Eric Hodel <drbrain@...7.net> 2006/09/09

On Sep 8, 2006, at 10:10 PM, Sean E. Russell wrote:

Re: RDoc patch, possible bug in socket.c for TCPSocket.new

From: gwtmp01@...
Date: 2006-09-26 22:47:40 UTC
List: ruby-core #8932
On Sep 26, 2006, at 5:35 PM, Daniel Berger wrote:
>>> Also, if I try to connect while it's in a TIME_WAIT state, I get  
>>> this:
>>>
>>> tcpsocket.rb:5:in `initialize': Address family not supported by  
>>> protocol
>>> family - bind(2) (Errno::EAFNOSUPPORT)
>>>        from tcpsocket.rb:5
>> Is this an error from the client trying to connect to the server  
>> in the TIME_WAIT
>> state or is this the error you are getting from the server trying  
>> to restart and
>> bind and reuse the local port that is still in the TIME_WAIT state?
>
> I get that error if I try to run the same script again before the  
> OS has closed the connection.  I'm expecting an error, just not  
> *that* error.  It's not a major issue, mind you.  I just thought it  
> was odd.
>
>> You use of the word 'connect' is a bit confusing since that is not  
>> generally used
>> to describe the behavior of a TCP server.
>
> I'm not sure where you mean? In my rdoc patch? I'm sure it could  
> use improvement - I'm hoping people on the list can improve the  
> wording.

I was a bit confused.  I was thinking your code implemented a server  
but you were coding a client establishing a connection to a local  
telnet server.  So when you said 'if I try to connect', I  
misunderstood you.

My comments regarding TIME_WAIT still apply.

Normally a client program does not specify a local port and the  
kernel picks an ephemeral port number for each connection.  In this  
case when you restart the client the kernel picks a different  
(unused) ephemeral port, you don't end up using the same (remote  
host,remote port, local host, local port) tuple and so you don't have  
a conflict with the previous TCP session which is still in the  
TIME_WAIT state.

If you explicitly choose a local host and local port then when you  
restart the client you'll be in conflict with the previous session  
and should get a something like an EADDRINUSE error, which is what I  
get on Mac OS X when I repeated your example (ruby 1.8.5).

So normally a client doesn't have a problem with TIME_WAIT because it  
uses a different port each time but a *server* that is stopped and  
restarted quickly can have a problem with TIME_WAIT because a server  
almost always binds to an explicit port (80 for an web server, for  
example).

What OS are you testing this on that you get an EAFNOSUPPORT error  
when you rerun the program before the TIME_WAIT expires?


Gary Wright




In This Thread