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 bpo-1736190 do not fix this case.

Patch against r63534 fix the issue.

Oh, I've just realised that FreeBSD is too fast. test_async_connect.py
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
machine.

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 "index.py", line 34, in <module>
    test()
  File "index.py", line 31, in test
    asyncore.loop(use_poll=1)
  File "/usr/lib/python2.5/asyncore.py", line 205, in loop
    poll_fun(timeout, map)
  File "/usr/lib/python2.5/asyncore.py", line 190, in poll2
    readwrite(obj, flags)
  File "/usr/lib/python2.5/asyncore.py", line 101, in readwrite
    obj.handle_error()
  File "/usr/lib/python2.5/asyncore.py", line 93, in readwrite
    obj.handle_read_event()
  File "/usr/lib/python2.5/asyncore.py", line 400, in handle_read_event
    self.handle_connect()
  File "index.py", line 17, in handle_connect
    self.send("hello world")
  File "/usr/lib/python2.5/asyncore.py", line 481, in send
    self.initiate_send()
  File "/usr/lib/python2.5/asyncore.py", line 468, in initiate_send
    num_sent = dispatcher.send(self, self.out_buffer[:512])
  File "/usr/lib/python2.5/asyncore.py", 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.

Oh, fine. May be handle_error should have been called, but anyway not
handle_connect.

But in my mind, handle_expt is better.

Here is a new patch against r64768

The new patch raise an exception if asynchronous connect fails.

This should have already been fixed in r64062.

I've got the same error in r64768.

Assigning this to me. The patch looks correct, it only needs tests assuming it is possible to write a reliable test for this.

Fixed in r83703 (2.7), r83704 (2.6), r83705 (3.2) and r83706 (3.1).
Thanks for the patch.

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.

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)

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.

I agree w/mvl. Giampaolo, please revert this for 2.6.6.

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.

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.

Ok, no problem. Reverted in r83969.

Just to close the loop: thanks for reverting this for 2.6.6!