[ python-Bugs-1019808 ] wrong socket error returned

Fri Aug 4 07:34:45 CEST 2006

Bugs item #1019808, was opened at 2004-08-31 09:18
Message generated for change (Comment added) made by nnorwitz
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.3
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: Neal Norwitz (nnorwitz)
Date: 2006-08-03 22: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 07: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 07: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 07: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 07: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 12: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 12: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-02 23: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 02: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 20: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 09: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