GNU bug report logs - #23615
25.1.50; Which platforms can safely use getsockopt(,,SO_ERROR,,)?

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 23615 in the body.
You can then email your comments to 23615 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Ken Brown <kbrown <at> cornell.edu>
To: bug-gnu-emacs <at> gnu.org
Subject: 25.1.50; Which platforms can safely use getsockopt(,,SO_ERROR,,)?
Date: Tue, 24 May 2016 20:26:13 -0400

There are two places in process.c where getsockopt(,,SO_ERROR,,) is
used to check the status of a socket connection attempt.  The first is
at line 3289, where it is done on all platforms except MS Windows.  The
second is at line 5500, where it is done only on GNU/Linux:

#ifdef GNU_LINUX
	      /* getsockopt(,,SO_ERROR,,) is said to hang on some systems.
		 So only use it on systems where it is known to work.  */
	      {
		socklen_t xlen = sizeof (xerrno);
		if (getsockopt (channel, SOL_SOCKET, SO_ERROR, &xerrno, &xlen))
		  xerrno = errno;
	      }
#else
	      {
		struct sockaddr pname;
		socklen_t pnamelen = sizeof (pname);

		/* If connection failed, getpeername will fail.  */
		xerrno = 0;
		if (getpeername (channel, &pname, &pnamelen) < 0)
		  {
		    /* Obtain connect failure code through error slippage.  */
		    char dummy;
		    xerrno = errno;
		    if (errno == ENOTCONN && read (channel, &dummy, 1) < 0)
		      xerrno = errno;
		  }
	      }
#endif

It would be better to use it on as many platforms as possible, since
it's much more likely to give the real reason for a connection failure
than the "error slippage" method.

Ken

Message #8 received at 23615 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Ken Brown <kbrown <at> cornell.edu>
Cc: 23615 <at> debbugs.gnu.org
Subject: Re: bug#23615: 25.1.50;
 Which platforms can safely use getsockopt(,,SO_ERROR,,)?
Date: Wed, 25 May 2016 19:24:45 +0300

> From: Ken Brown <kbrown <at> cornell.edu>
> Date: Tue, 24 May 2016 20:26:13 -0400
> 
> There are two places in process.c where getsockopt(,,SO_ERROR,,) is
> used to check the status of a socket connection attempt.  The first is
> at line 3289, where it is done on all platforms except MS Windows.  The
> second is at line 5500, where it is done only on GNU/Linux:

FYI, the first instance is ifdef'ed away for Windows because we can
never have EINTR on Windows, and the surrounding code that handles
that case is tricky to get to compile on Windows (since we override
the definitions of FD_* macros with our own).  MS-Windows does support
SO_ERROR.

> It would be better to use it on as many platforms as possible, since
> it's much more likely to give the real reason for a connection failure
> than the "error slippage" method.

Perhaps you or someone could write a small test program, and then
people here could run it various platforms and provide feedback.

Message #11 received at 23615 <at> debbugs.gnu.org (full text, mbox):

From: Ken Brown <kbrown <at> cornell.edu>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 23615 <at> debbugs.gnu.org
Subject: Re: bug#23615: 25.1.50; Which platforms can safely use
 getsockopt(,,SO_ERROR,,)?
Date: Wed, 25 May 2016 15:21:56 -0400

[Message part 1 (text/plain, inline)]

On 5/25/2016 12:24 PM, Eli Zaretskii wrote:
> Perhaps you or someone could write a small test program, and then
> people here could run it various platforms and provide feedback.

Test program attached.  It simulates the situation of bug 23606 (before 
the bug was fixed).  Here's what happens on Cygwin:

$ gcc -o socket_test socket_test.c

$ ./socket_test.exe
Server listening on port 50176.
Attempting client connection...failure: Connection refused.

Ken

[socket_test.c (text/plain, attachment)]

Message #14 received at 23615 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Ken Brown <kbrown <at> cornell.edu>
Cc: 23615 <at> debbugs.gnu.org
Subject: Re: bug#23615: 25.1.50; Which platforms can safely use
 getsockopt(,,SO_ERROR,,)?
Date: Sat, 28 May 2016 15:57:00 +0300

[Message part 1 (text/plain, inline)]

> Cc: 23615 <at> debbugs.gnu.org
> From: Ken Brown <kbrown <at> cornell.edu>
> Date: Wed, 25 May 2016 15:21:56 -0400
> 
> On 5/25/2016 12:24 PM, Eli Zaretskii wrote:
> > Perhaps you or someone could write a small test program, and then
> > people here could run it various platforms and provide feedback.
> 
> Test program attached.  It simulates the situation of bug 23606 (before 
> the bug was fixed).  Here's what happens on Cygwin:
> 
> $ gcc -o socket_test socket_test.c
> 
> $ ./socket_test.exe
> Server listening on port 50176.
> Attempting client connection...failure: Connection refused.

With MinGW, I get this instead:

  D:\usr\eli\data>socket_test
  Server listening on port 2213.
  Attempting client connection...success.

Do we have to have a failure in this case?  Or is the above a valid
outcome?

Of course, I needed to hack the code quite a lot to get it compile on
MS-Windows; the result is attached below.  Maybe I broke the code
while doing that?

(I don't think calling 'connect' after 'listen' is supposed to work;
on Windows it predictably fails with EINVAL, as documented on MSDN.)

[socket_test.c (application/octet-stream, attachment)]

Message #17 received at 23615 <at> debbugs.gnu.org (full text, mbox):

From: Ken Brown <kbrown <at> cornell.edu>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 23615 <at> debbugs.gnu.org
Subject: Re: bug#23615: 25.1.50; Which platforms can safely use
 getsockopt(,,SO_ERROR,,)?
Date: Sat, 28 May 2016 13:18:27 -0400

On 5/28/2016 8:57 AM, Eli Zaretskii wrote:
>> From: Ken Brown <kbrown <at> cornell.edu>

>> Test program attached.  It simulates the situation of bug 23606 (before
>> the bug was fixed).  Here's what happens on Cygwin:
>>
>> $ gcc -o socket_test socket_test.c
>>
>> $ ./socket_test.exe
>> Server listening on port 50176.
>> Attempting client connection...failure: Connection refused.
>
> With MinGW, I get this instead:
>
>   D:\usr\eli\data>socket_test
>   Server listening on port 2213.
>   Attempting client connection...success.
>
> Do we have to have a failure in this case?  Or is the above a valid
> outcome?

It's a valid outcome.  I think the reason the connection is refused on 
Cygwin (and apparently on RHEL 7.2) is that the first addrinfo structure 
returned by getaddrinfo has an IPv6 address.  There's no reason to 
expect this to happen on all platforms.

> Of course, I needed to hack the code quite a lot to get it compile on
> MS-Windows; the result is attached below.  Maybe I broke the code
> while doing that?

No, you didn't.  I get the same results as before with your version, 
after fixing a couple of typos that don't affect the MinGW build.  (You 
forgot a semicolon at the end of line 41, and you misspelled "strerror" 
in line 126.)

> (I don't think calling 'connect' after 'listen' is supposed to work;
> on Windows it predictably fails with EINVAL, as documented on MSDN.)

I think on Posix systems it fails with EISCONN.  I put the call in 
because it's done in the code in process.c that I was imitating, but 
omitting it as you did is fine also.

Thanks for testing.

Ken

Message #20 received at 23615 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Ken Brown <kbrown <at> cornell.edu>
Cc: 23615 <at> debbugs.gnu.org
Subject: Re: bug#23615: 25.1.50; Which platforms can safely use
 getsockopt(,,SO_ERROR,,)?
Date: Sat, 28 May 2016 20:48:45 +0300

> Cc: 23615 <at> debbugs.gnu.org
> From: Ken Brown <kbrown <at> cornell.edu>
> Date: Sat, 28 May 2016 13:18:27 -0400
> 
> > With MinGW, I get this instead:
> >
> >   D:\usr\eli\data>socket_test
> >   Server listening on port 2213.
> >   Attempting client connection...success.
> >
> > Do we have to have a failure in this case?  Or is the above a valid
> > outcome?
> 
> It's a valid outcome.  I think the reason the connection is refused on 
> Cygwin (and apparently on RHEL 7.2) is that the first addrinfo structure 
> returned by getaddrinfo has an IPv6 address.  There's no reason to 
> expect this to happen on all platforms.

OK, thanks.  So hopefully others will chime in with results from other
platforms.

Message #23 received at 23615 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Ken Brown <kbrown <at> cornell.edu>
Cc: 23615 <at> debbugs.gnu.org
Subject: Re: bug#23615: 25.1.50; Which platforms can safely use
 getsockopt(,,SO_ERROR,,)?
Date: Thu, 2 Jun 2016 09:00:00 -0700

On Solaris 10 on a host with only IPv4 configured, socket_test.c fails 
with the diagnostic "Can't start server." 'truss' says connect(3, 
0x00021EE8, 16, SOV_DEFAULT) failed with errno == EOPNOTSUPP.

On Solaris 11 with both IPv4 and IPv6, the same symptoms except errno == 
EADDRNOTAVAIL.

Message #26 received at 23615 <at> debbugs.gnu.org (full text, mbox):

From: Ken Brown <kbrown <at> cornell.edu>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: 23615 <at> debbugs.gnu.org
Subject: Re: bug#23615: 25.1.50; Which platforms can safely use
 getsockopt(,,SO_ERROR,,)?
Date: Thu, 2 Jun 2016 13:17:34 -0400

On 6/2/2016 12:00 PM, Paul Eggert wrote:
> On Solaris 10 on a host with only IPv4 configured, socket_test.c fails
> with the diagnostic "Can't start server." 'truss' says connect(3,
> 0x00021EE8, 16, SOV_DEFAULT) failed with errno == EOPNOTSUPP.
>
> On Solaris 11 with both IPv4 and IPv6, the same symptoms except errno ==
> EADDRNOTAVAIL.

Thanks for testing.  This means that my test program is not portable 
enough to answer the question in the subject; the failure occurred 
before the program reached the getsockopt call.  I'll see if I can fix that.

Ken

Message #29 received at 23615 <at> debbugs.gnu.org (full text, mbox):

From: Ken Brown <kbrown <at> cornell.edu>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: 23615 <at> debbugs.gnu.org
Subject: Re: bug#23615: 25.1.50; Which platforms can safely use
 getsockopt(,,SO_ERROR,,)?
Date: Thu, 2 Jun 2016 13:55:14 -0400

On 6/2/2016 1:17 PM, Ken Brown wrote:
> On 6/2/2016 12:00 PM, Paul Eggert wrote:
>> On Solaris 10 on a host with only IPv4 configured, socket_test.c fails
>> with the diagnostic "Can't start server." 'truss' says connect(3,
>> 0x00021EE8, 16, SOV_DEFAULT) failed with errno == EOPNOTSUPP.
>>
>> On Solaris 11 with both IPv4 and IPv6, the same symptoms except errno ==
>> EADDRNOTAVAIL.
>
> Thanks for testing.  This means that my test program is not portable
> enough to answer the question in the subject; the failure occurred
> before the program reached the getsockopt call.  I'll see if I can fix
> that.

I wonder if the problem was calling 'connect' after calling 'listen'. 
Eli pointed out that this doesn't work on MS-Windows, and in any case I 
can't see why it would ever be needed.  (I only did it because the code 
in process.c that I was imitating did it.)

Does the following help?

--- socket_test.c~      2016-05-25 21:27:46.000000000 -0400
+++ socket_test.c       2016-06-02 13:47:52.719883900 -0400
@@ -122,6 +122,7 @@
            return -1;
          }
          *pservice = ntohs (sa.sin_port);
+         ret = 0;
        }
       else
        /* Nonblocking client.  */
@@ -132,8 +133,8 @@
              s = -1;
              continue;
            }
+         ret = connect (s, rp->ai_addr, rp->ai_addrlen);
        }
-      ret = connect (s, rp->ai_addr, rp->ai_addrlen);
       if (ret == 0 || errno == EISCONN)
        break;
       if (!server && errno == EINPROGRESS)

Message #32 received at 23615 <at> debbugs.gnu.org (full text, mbox):

From: Ken Brown <kbrown <at> cornell.edu>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: 23615 <at> debbugs.gnu.org
Subject: Re: bug#23615: 25.1.50; Which platforms can safely use
 getsockopt(,,SO_ERROR,,)?
Date: Thu, 2 Jun 2016 14:55:07 -0400

On 6/2/2016 1:55 PM, Ken Brown wrote:
> I wonder if the problem was calling 'connect' after calling 'listen'.
> Eli pointed out that this doesn't work on MS-Windows, and in any case I
> can't see why it would ever be needed.  (I only did it because the code
> in process.c that I was imitating did it.)

Sorry, I misread the code.  process.c doesn't call 'connect' after 
calling 'listen'.

Ken

Message #37 received at 23615-done <at> debbugs.gnu.org (full text, mbox):

From: Ken Brown <kbrown <at> cornell.edu>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: 23615-done <at> debbugs.gnu.org
Subject: Re: bug#23615: 25.1.50; Which platforms can safely use
 getsockopt(,,SO_ERROR,,)?
Date: Fri, 10 Jun 2016 08:38:36 -0400

I see that you've made the change I suggested, so my test program is no 
longer relevant.  I'm closing the bug.

Ken

Message #40 received at 23615-done <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Ken Brown <kbrown <at> cornell.edu>
Cc: 23615-done <at> debbugs.gnu.org
Subject: Re: bug#23615: 25.1.50; Which platforms can safely use
 getsockopt(,,SO_ERROR,,)?
Date: Fri, 10 Jun 2016 10:48:36 -0700

Ken Brown wrote:
> I see that you've made the change I suggested, so my test program is no longer
> relevant.  I'm closing the bug.

Thanks, to be honest I had forgotten all about the bug! I ran into this problem 
again why trying to fix another bug, and this patch was separable from the main 
fix (which I haven't installed yet).

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.