[ python-Bugs-1019808 ] wrong socket error returned

Tue Aug 8 14:15:28 CEST 2006

Bugs item #1019808, was opened at 2004-08-31 12:18
Message generated for change (Settings changed) made by akuchling
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1019808&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Extension Modules
>Group: Python 2.6
Status: Open
Resolution: None
Priority: 5
Submitted By: Federico Schwindt (fgsch)
Assigned to: A.M. Kuchling (akuchling)
Summary: wrong socket error returned

Initial Comment:
hi,

  first, background:

  OS: OpenBSD-current/i386
  Python version: 2.3.4

   example script:

import socket

socket.setdefaulttimeout(30)

s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
s.connect(('127.0.0.1', 9999))

   where nothing is listening on 9999 (ECONNREFUSED
should be returned).
   when ran it i get:

Traceback (most recent call last):
  File "bug.py", line 8, in ?
    s.connect(('127.0.0.1', 9999))
  File "<string>", line 1, in connect
socket.error: (22, 'Invalid argument')

  this is a problem in the socketmodule.c, in the
internal_connect() function. getsockopt with SOCK_ERROR
should be used once EINPROGRESS is returned to get the
real error.
  this code works on linux, but the connect semantic
is, imho, broken. you cannot reuse a socket once it
failed (a test afterwards shown that this is valid
under linux!!!!).
  please contact me if you need further details,
although i find this very clear.
  thanks,

  f.-

----------------------------------------------------------------------

>Comment By: A.M. Kuchling (akuchling)
Date: 2006-08-08 08:15

Message:
Logged In: YES 
user_id=11375

I agree -- this sort of Unix-platform-specific bugfix is
always risky.  It would have been better if this patch could
have been committed in one of the alphas.

I'll put this bug in the Python 2.6 group and commit it
after 2.5final is released (perhaps it can also go on the
release25-maint branch at that time).

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-08-04 01:34

Message:
Logged In: YES 
user_id=33168

Andrew, I'm ok with this patch, but not enthusiastic for
2.5.  It might be better to wait for 2.5.1 in order to give
this more time to settle.  I agree that this change *should*
be correct, but who knows if it will break some other
platform(s).  I leave it to you whether to apply for 2.5 or
2.5.1.  It would be good to actually test this condition too.

----------------------------------------------------------------------

Comment By: A.M. Kuchling (akuchling)
Date: 2006-08-03 10:31

Message:
Logged In: YES 
user_id=11375

Deleting broken patches; attaching a correct version against
2.5 trunk.

----------------------------------------------------------------------

Comment By: A.M. Kuchling (akuchling)
Date: 2006-08-03 10:18

Message:
Logged In: YES 
user_id=11375

I can confirm the bug on MacOS X, and the failure of the
patch to fix it.

I think the logic of the patch is wrong; it saves errno in
save_errno when errno==EINPROGRESS, does a getsockopt(), and
then resets errno to save_errno, which we know is
EINPROGRESS.  I think the correct action is to do 'errno =
<result of the getsockopt>".

Revised patch attached; it produces the correct result on OS X.

----------------------------------------------------------------------

Comment By: A.M. Kuchling (akuchling)
Date: 2006-08-03 10:15

Message:
Logged In: YES 
user_id=11375

I can confirm the bug on MacOS X, and the failure of the
patch to fix it.

I think the logic of the patch is wrong; it saves errno in
save_errno when errno==EINPROGRESS, does a getsockopt(), and
then resets errno to save_errno, which we know is
EINPROGRESS.  I think the correct action is to do 'errno =
<result of the getsockopt>".

Revised patch attached; it produces the correct result on OS X.

----------------------------------------------------------------------

Comment By: A.M. Kuchling (akuchling)
Date: 2006-08-03 10:14

Message:
Logged In: YES 
user_id=11375

I can confirm the bug on MacOS X, and the failure of the
patch to fix it.

I think the logic of the patch is wrong; it saves errno in
save_errno when errno==EINPROGRESS, does a getsockopt(), and
then resets errno to save_errno, which we know is
EINPROGRESS.  I think the correct action is to do 'errno =
<result of the getsockopt>".

Revised patch attached; it produces the correct result on OS X.

----------------------------------------------------------------------

Comment By: Frank Vercruesse (vercruesse)
Date: 2006-02-17 15:46

Message:
Logged In: YES 
user_id=202246

I can confirm the bug running Python 2.4.2 on Mac OS X
10.4.5 (PPC). However, the patch doesn't seem to resolve the
issue. Now I get the following traceback when running the
posted script:

Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "<string>", line 1, in connect
socket.error: (36, 'Operation now in progress')

----------------------------------------------------------------------

Comment By: Federico Schwindt (fgsch)
Date: 2005-10-03 15:44

Message:
Logged In: YES 
user_id=50493

patch against 2.4.1 appended. not tested in anything but
openbsd. nevertheless, i think it should work in linux and
osx. not sure about others.
cheers.

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2005-10-03 02:02

Message:
Logged In: YES 
user_id=33168

Can you provide a patch that you believe corrects this problem?

----------------------------------------------------------------------

Comment By: Federico Schwindt (fgsch)
Date: 2005-06-24 05:41

Message:
Logged In: YES 
user_id=50493

just tried this with 2.4.1 running in OpenBSD 3.7/amd64 and
the problem is still there :-(

----------------------------------------------------------------------

Comment By: Federico Schwindt (fgsch)
Date: 2004-09-22 23:58

Message:
Logged In: YES 
user_id=50493

any news? this may be a problem in other *BSDs as well..

----------------------------------------------------------------------

Comment By: Federico Schwindt (fgsch)
Date: 2004-08-31 12:22

Message:
Logged In: YES 
user_id=50493

maybe i was not clear. the problem is only happening when
setdefaulttimeout is used. otherwise ECONNREFUSED is
correctly returned.

f.-

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1019808&group_id=5470