Title: asyncore doesn't handle connection refused correctly
Type: behavior Stage:
Components: Library (Lib) Versions: Python 3.1, Python 3.2, Python 2.7, Python 2.6
Status: closed Resolution: fixed
Dependencies: Superseder:
Assigned To: giampaolo.rodola Nosy List: barry, forest, giampaolo.rodola, intgr, josiah.carlson, josiahcarlson, loewis, r.david.murray, shigin
Priority: release blocker Keywords: patch

Created on 2008-05-22 13:23 by shigin, last changed 2010-08-14 00:46 by barry. This issue is now closed.

File name Uploaded Description Edit shigin, 2008-05-22 13:23 simple test example, it works only if none listens on port 9090
asyncore-connect-patch.diff shigin, 2008-07-08 13:27
Messages (18)
msg67188 - (view) Author: Alexander Shigin (shigin) Date: 2008-05-22 13:23
Unix select returns socket in read fd set and write fd set if 
nonblocking socket attempts to connect to unaviable address. 

asyncore should check this case by calling getsockopt with SO_ERROR 
optname. If return value is 0 it should call handle_connect_event, 
otherwise if should call handle_expt_event.

Attached file prints "get exception" if asyncore can't connect to 
remote side, not "uncaptured python exception"

Patches from Issue1736190 do not fix this case.
msg67189 - (view) Author: Alexander Shigin (shigin) Date: 2008-05-22 13:26
Patch against r63534 fix the issue.
msg67196 - (view) Author: Alexander Shigin (shigin) Date: 2008-05-22 15:52
Oh, I've just realised that FreeBSD is too fast. 
works fine on linux box, but on FreeBSD i need to change localhost to 
another host :(

I haven't got any idea how to make a test case which work on any 
msg67306 - (view) Author: Giampaolo Rodola' (giampaolo.rodola) * (Python committer) Date: 2008-05-24 18:25
By trying your script on Linux and Windows I notice different behaviors.
On Windows handle_expt is always called.
On Linux, no matter if using select or poll, handle_accept is called,
then an exception is thrown at the time the data is going to be sent:

Traceback (most recent call last):
  File "", line 34, in <module>
  File "", line 31, in test
  File "/usr/lib/python2.5/", line 205, in loop
    poll_fun(timeout, map)
  File "/usr/lib/python2.5/", line 190, in poll2
    readwrite(obj, flags)
  File "/usr/lib/python2.5/", line 101, in readwrite
  File "/usr/lib/python2.5/", line 93, in readwrite
  File "/usr/lib/python2.5/", line 400, in handle_read_event
  File "", line 17, in handle_connect
    self.send("hello world")
  File "/usr/lib/python2.5/", line 481, in send
  File "/usr/lib/python2.5/", line 468, in initiate_send
    num_sent = dispatcher.send(self, self.out_buffer[:512])
  File "/usr/lib/python2.5/", line 345, in send
    result = self.socket.send(data)
socket.error: (111, 'Connection refused')

In my opinion both behaviors are wrong since neither handle_expt nor
handle_connect should be called in case of a "connection refused" event.
Especially handle_connect should not be called at all since no
connection takes place.
The correct behavior here must be identifying when such event occurs,
raise the proper exception (ECONNREFUSED) and let it propagate until
handle_error which will take care of it.
msg67308 - (view) Author: Alexander Shigin (shigin) Date: 2008-05-24 19:02
Oh, fine. May be handle_error should have been called, but anyway not 

But in my mind, handle_expt is better.
msg69427 - (view) Author: Alexander Shigin (shigin) Date: 2008-07-08 13:27
Here is a new patch against r64768

The new patch raise an exception if asynchronous connect fails.
msg74125 - (view) Author: Giampaolo Rodola' (giampaolo.rodola) * (Python committer) Date: 2008-10-01 11:29
This should have already been fixed in r64062.
msg74127 - (view) Author: Alexander Shigin (shigin) Date: 2008-10-01 12:01
I've got the same error in r64768.
msg112704 - (view) Author: Giampaolo Rodola' (giampaolo.rodola) * (Python committer) Date: 2010-08-03 22:06
Assigning this to me. The patch looks correct, it only needs tests assuming it is possible to write a reliable test for this.
msg112775 - (view) Author: Giampaolo Rodola' (giampaolo.rodola) * (Python committer) Date: 2010-08-04 09:05
Fixed in r83703 (2.7), r83704 (2.6), r83705 (3.2) and r83706 (3.1).
Thanks for the patch.
msg113707 - (view) Author: Barry A. Warsaw (barry) * (Python committer) Date: 2010-08-12 21:27
The fix for this was applied after 2.6.6rc1, and it wasn't approved by me.  Is it critical for 2.6?  Is it a regression since 2.6.5?  The way I see it, we either back this out or release an rc2.  There may be other reasons to release an rc2, but I need to verify that that is possible for MvL.
msg113709 - (view) Author: Martin v. Löwis (loewis) * (Python committer) Date: 2010-08-12 21:46
What date would the final release then be made? It would be best if it could be done before Aug 27. If necessary, I could also make a release on September 6 (but not any day before or after)
msg113710 - (view) Author: Martin v. Löwis (loewis) * (Python committer) Date: 2010-08-12 21:50
The bug is not a regression since 2.6.5; AFAICT, it was in Python "forever". I recommend to revert the checkin, and postpone fixing it to 2.7.1.
msg113715 - (view) Author: Barry A. Warsaw (barry) * (Python committer) Date: 2010-08-12 22:46
I agree w/mvl.  Giampaolo, please revert this for 2.6.6.
msg113730 - (view) Author: Giampaolo Rodola' (giampaolo.rodola) * (Python committer) Date: 2010-08-13 01:04
The commit was made on August 04, 11:05 AM, while rc1 was released at 06:09 PM.
I don't think the patch is going to introduce any problem but if you think it's the case to revert it then I'll do it.
msg113733 - (view) Author: R. David Murray (r.david.murray) * (Python committer) Date: 2010-08-13 01:18
The question isn't when it was released, but when it was tagged, and that happened at Aug 3 22:51:57 2010 UTC according to svn.  Your commit was made Aug 4 08:58:38 2010 UTC.
msg113735 - (view) Author: Giampaolo Rodola' (giampaolo.rodola) * (Python committer) Date: 2010-08-13 01:31
Ok, no problem. Reverted in r83969.
msg113857 - (view) Author: Barry A. Warsaw (barry) * (Python committer) Date: 2010-08-14 00:46
Just to close the loop: thanks for reverting this for 2.6.6!
Date User Action Args
2010-08-14 00:46:44barrysetmessages: + msg113857
2010-08-13 08:50:17loewissetstatus: open -> closed
2010-08-13 01:31:42giampaolo.rodolasetmessages: + msg113735
2010-08-13 01:18:25r.david.murraysetnosy: + r.david.murray
messages: + msg113733
2010-08-13 01:04:12giampaolo.rodolasetmessages: + msg113730
2010-08-12 22:46:23barrysetmessages: + msg113715
2010-08-12 21:50:35loewissetmessages: + msg113710
2010-08-12 21:46:08loewissetmessages: + msg113709
2010-08-12 21:27:21barrysetstatus: closed -> open
priority: normal -> release blocker
2010-08-12 21:27:08barrysetnosy: + loewis, barry
messages: + msg113707
2010-08-04 09:05:48giampaolo.rodolasetstatus: open -> closed
resolution: fixed
messages: + msg112775

versions: + Python 2.6, Python 3.1, Python 3.2
2010-08-03 22:06:05giampaolo.rodolasetassignee: giampaolo.rodola
messages: + msg112704
2010-08-03 19:38:35terry.reedysetversions: + Python 2.7, - Python 2.6, Python 2.5
2009-03-28 12:13:53intgrsetnosy: + intgr
2008-12-18 01:56:45forestsetnosy: + forest
2008-10-01 12:01:12shiginsetmessages: + msg74127
2008-10-01 11:29:40giampaolo.rodolasetmessages: + msg74125
2008-07-08 13:44:56shiginsetfiles: - asyncore-connect-patch.diff
2008-07-08 13:27:08shiginsetfiles: + asyncore-connect-patch.diff
messages: + msg69427
2008-05-24 19:02:50shiginsetmessages: + msg67308
2008-05-24 18:26:10giampaolo.rodolasetmessages: + msg67306
2008-05-24 15:13:10giampaolo.rodolasetnosy: + josiahcarlson, giampaolo.rodola, josiah.carlson
2008-05-22 15:52:14shiginsetmessages: + msg67196
2008-05-22 13:26:07shiginsetfiles: + asyncore-connect-patch.diff
keywords: + patch
messages: + msg67189
2008-05-22 13:23:58shigincreate