[issue5798] test_asynchat fails on Mac OSX

Mark Dickinson added the comment: Josiah's fix in r73182 applies cleanly to the release26-maint branch, and fixes (for me, at least) the current OS X failures in test_asynchat and test_smtplib. I've attached a patch with the backport of this fix, and a Misc/NEWS entry. Barry, can this go in

[issue5798] test_asynchat fails on Mac OSX

Barry A. Warsaw added the comment: Thanks Mark, go ahead and apply this, then close this issue. -- resolution: -> accepted ___ Python tracker ___ ___

[issue5798] test_asynchat fails on Mac OSX

Mark Dickinson added the comment: Applied in r83718. -- status: open -> closed ___ Python tracker ___ ___ Python-bugs-list mailing lis

[issue5798] test_asynchat fails on Mac OSX

Changes by Mark Dickinson : -- resolution: accepted -> fixed stage: needs patch -> committed/rejected ___ Python tracker ___ ___ Python

[issue5798] test_asynchat fails on Mac OSX

Ned Deily added the comment: Still happening on 3.1rc1. Should this be considered a release blocker for 3.1? -- nosy: +benjamin.peterson, nad ___ Python tracker ___

[issue5798] test_asynchat fails on Mac OSX

Josiah Carlson added the comment: If it's failing, and asyncore is still in 3.1, then I would argue yes. I'll submit a fix to trunk and 3.1 based on my version below (unless anyone has any outstanding concerns, or believes that it doesn't work for them). -- _

[issue5798] test_asynchat fails on Mac OSX

Changes by Benjamin Peterson : -- priority: high -> release blocker ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscrib

[issue5798] test_asynchat fails on Mac OSX

Changes by Josiah Carlson : Removed file: http://bugs.python.org/file13934/asyncore_fix_mac_2.patch ___ Python tracker ___ ___ Python-bugs-list

[issue5798] test_asynchat fails on Mac OSX

Josiah Carlson added the comment: Fixed in trunk in 73182, fixed in py3k in 73183. Closing as fixed. -- resolution: -> fixed status: open -> closed ___ Python tracker ___ _

[issue5798] test_asynchat fails on Mac OSX

Ned Deily added the comment: Verified test_asynchat no longer fails in trunk nor py3k. Thanks! -- ___ Python tracker ___ ___ Python-b

[issue5798] test_asynchat fails on Mac OSX

Jean Brouwers added the comment: Well, with fresh build of Python 3.1rc1 on MacOS X 10.4.11 Tiger (Intel) test_asynchat.py rev 73183 still seems to fail, perhaps differently. Here is 3 different results. First, rev 73183: % ./python.exe Lib/test/test_asynchat73183.py test_close_when_done (

[issue5798] test_asynchat fails on Mac OSX

R. David Murray added the comment: I presume you mean "a fresh build of 3.1rc1+" (from svn)? 3.1rc1 does not contain the most recent fix. -- ___ Python tracker ___ _

[issue5798] test_asynchat fails on Mac OSX

Josiah Carlson added the comment: I installed 3.1rc1 on my OS X (10.5.?) machine, updated asynchat, and ran the test with and without my change. Without my change, it breaks in the way described numerous times. With my change, it seems to work fine on OS X, linux, and Windows for me. Looki

[issue5798] test_asynchat fails on Mac OSX

Jean Brouwers added the comment: Correct. With new Lib/asyncore.py file rev 73183 all 23 tests in the original test_asynchat.py pass in Python 3.1rc1 built from source on MacOS X 10.4.11 Tiger (Intel). % ./python.exe Lib/test/test_asynchat.py test_close_when_done (__main__.TestAsynchat) ...

[issue5798] test_asynchat fails on Mac OSX

New submission from Ismail Donmez : Using latest python 2.6 branch; test_asynchat fails with the following error: error: uncaptured python exception, closing channel (:[Errno 9] Bad file descriptor [/Users/cartman/Sources/python-2.6/Lib/asyncore.py|readwrite|107] [/Users/cartman/Sources/python-

[issue5798] test_asynchat fails on Mac OSX

Mark Dickinson added the comment: I'm seeing this failure on 2.7, 3.0 and 3.1 as well. -- nosy: +marketdickinson priority: -> high versions: +Python 2.7, Python 3.0, Python 3.1 ___ Python tracker _

[issue5798] test_asynchat fails on Mac OSX

Ismail Donmez added the comment: Still fails in 3.1 beta1. -- ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: h

[issue5798] test_asynchat fails on Mac OSX

Mark Dickinson added the comment: I tried to track this down, but ran out of time. Here's the little that I discovered; maybe someone else with access to OS X (which I have) and an understanding of poll (which I lack) can build on this. The failure has to do with select.poll differences betwe

[issue5798] test_asynchat fails on Mac OSX

Mark Dickinson added the comment: r56632 looks relevant: """When running asynchat tests on OS X (darwin), the test client now overrides asyncore.dispatcher.handle_expt to do nothing, since select.poll gives a POLLHUP error at the completion of these tests. Added timeout & count arguments to sev

[issue5798] test_asynchat fails on Mac OSX

Jean Brouwers added the comment: Here is a (new?) failure of test_asynchat with Python 3.1b1 on MacOS X 10.4.11 (Intel). % make test test test_asynchat produced unexpected output: ** *** lines 2-16 of actual output doesn'

[issue5798] test_asynchat fails on Mac OSX

R. David Murray added the comment: See also issue 1161031, especially Giampaolo's suggestion near the end. Seems like it might be relevant. I was the one who merged Josiah's trunk fix into othe other branches, to get things back into sync, but I don't claim to understand the code at any deep l

[issue5798] test_asynchat fails on Mac OSX

Josiah Carlson added the comment: Looking at trunk, it seems like one reasonable option is to swap the order of handle_close() and handle_expt_event() testing and calls. That would keep all reading/writing before handle_close(), which should be correct. -- _

[issue5798] test_asynchat fails on Mac OSX

Mark Dickinson added the comment: Josiah, that solution isn't working for me; it looks as though there's a deeper weirdness: what I'm seeing is that on OS X, in e.g. test_emptyline, we end up calling the readwrite function in asyncore.py with flags = POLLIN | POLLPRI | POLLHUP. The first t

[issue5798] test_asynchat fails on Mac OSX

Mark Dickinson added the comment: So the sequence of events seems to be: asyncore.readwrite calls obj.handle_read_event ... which calls obj.handle_read (3rd branch of handle_read_event) ... which is defined in asynchat.py; it calls obj.recv ... (back in asyncore now): recv calls obj.soc

[issue5798] test_asynchat fails on Mac OSX

Josiah Carlson added the comment: It would seem that we need to be more defensive in our calls. We need to check to make sure that the socket isn't closed before calling read/write/expt events. -- ___ Python tracker

[issue5798] test_asynchat fails on Mac OSX

Josiah Carlson added the comment: Mark, try this: if flags & select.POLLIN and (obj.connected or obj.accepting): obj.handle_read_event() if flags & select.POLLOUT and obj.connected: obj.handle_write_event() if flags & select.POLLPRI and obj.connec

[issue5798] test_asynchat fails on Mac OSX

Mark Dickinson added the comment: That fixes test_empty_line (in test_asynchat.py), but now I get a hang in test_close_when_done. By the way, here's an interesting site that goes some way to explaining what to expect from select.poll and EOF. http://www.greenend.org.uk/rjk/2001/06/poll.html

[issue5798] test_asynchat fails on Mac OSX

Josiah Carlson added the comment: Try getting rid of the "and" clause in the select.POLLIN . -- ___ Python tracker ___ ___ Python-bugs

[issue5798] test_asynchat fails on Mac OSX

Josiah Carlson added the comment: To be clear, make the first test read... if flags & select.POLLIN: obj.handle_read_event() -- ___ Python tracker ___ ___

[issue5798] test_asynchat fails on Mac OSX

Mark Dickinson added the comment: Getting rid of the and ... on the handle_read_event didn't make a difference: I still get the hang in test_close_when_done. But if I get rid of the and clause on the handle_write_event branch then all the test_asynchat tests pass. So that block now looks lik

[issue5798] test_asynchat fails on Mac OSX

Josiah Carlson added the comment: I went ahead and plugged my mac in (which reminded me of why I unplugged it in the first place), and I'm able to reproduce your error in the test after my proposed modifications. One thing to remember is that the test is broken; we rely on a .connected attri

[issue5798] test_asynchat fails on Mac OSX

Jean Brouwers added the comment: I reran the test_synchat.py test after patching to the Lib/asyncore.py and Lib/test/test-asynchat.py files of Python-3.1b1 on MacOS X 10.4.11 (Intel). The test now hangs in ... test_string_producer (__main__.TestAsynchat) ... ok test_close_when_done (__main__.

[issue5798] test_asynchat fails on Mac OSX

Josiah Carlson added the comment: As an aside, I was testing against trunk, not 3.1b1 . -- ___ Python tracker ___ ___ Python-bugs-list

[issue5798] test_asynchat fails on Mac OSX

Jean Brouwers added the comment: Understood. On Thu, May 7, 2009 at 5:18 PM, Josiah Carlson wrote: > > Josiah Carlson added the comment: > > As an aside, I was testing against trunk, not 3.1b1 . > > -- > > ___ > Python tracker >

[issue5798] test_asynchat fails on Mac OSX

Giampaolo Rodola' added the comment: Has anyone already tried to modify readwrite() as I was suggesting here? http://bugs.python.org/issue1161031#msg84892 -- ___ Python tracker _

[issue5798] test_asynchat fails on Mac OSX

Jean Brouwers added the comment: Indeed, the unmodified test_asynchat.py now passes in Python 3.1b1. The readwrite function in asyncore looks like this now: def readwrite(obj, flags): try: if flags & (select.POLLHUP | select.POLLERR | select.POLLNVAL): obj.handle_close

[issue5798] test_asynchat fails on Mac OSX

Josiah Carlson added the comment: One of the issues with using the method that Giampaolo describes, which I explained to him, is that generally if someone sends you data, you want to receive it. You can get both data and the signal that someone disconnected, in particular, with asynchat's .c

[issue5798] test_asynchat fails on Mac OSX

Mark Dickinson added the comment: With Josiah's patch, on trunk (r72475), test_asyncore passes, but test_asynchat is still hanging in the test: test_close_when_done (__main__.TestAsynchat_WithPoll) ... The hang occurs at the line "data = conn.recv(1)" in the run method of the echo_server clas

[issue5798] test_asynchat fails on Mac OSX

Mark Dickinson added the comment: With Giampaolo's suggested change, all tests pass. My understanding of what asyncore/asynchat is intended to do and how it might be used in practice is weak, so I don't feel qualified to comment on the correctness of the change. > One of the issues with usi

[issue5798] test_asynchat fails on Mac OSX

Josiah Carlson added the comment: Ok, so I was running "test_asyncore" and not "test_asynchat". The issue on OS X is that when a new socket is connecting, select.poll() shows the socket as being writable when it first connects, but using my variant, .connected is False while it's waiting for

[issue5798] test_asynchat fails on Mac OSX

Changes by Josiah Carlson : Removed file: http://bugs.python.org/file13915/asyncore_fix_mac.patch ___ Python tracker ___ ___ Python-bugs-list m

[issue5798] test_asynchat fails on Mac OSX

Changes by Josiah Carlson : Removed file: http://bugs.python.org/file13918/unnamed ___ Python tracker ___ ___ Python-bugs-list mailing list Uns

[issue5798] test_asynchat fails on Mac OSX

Mark Dickinson added the comment: asyncore_fix_mac_2.patch fixes all test_failures for me, on both trunk and py3k. -- ___ Python tracker ___

[issue5798] test_asynchat fails on Mac OSX

Josiah Carlson added the comment: Here's an option that doesn't use .connected, which some people have expressed distaste for. def readwrite(obj, flags): try: if flags & select.POLLIN: obj.handle_read_event() if flags & select.POLLOUT: obj.handle_wri

[issue5798] test_asynchat fails on Mac OSX

Giampaolo Rodola' added the comment: Even if that patch would fix this issue (and I'm pretty sure it does) I don't think it's a good idea handling all those errors (EBADF, ECONNRESET, ENOTCONN, ESHUTDOWN, ECONNABORTED) in readwrite() function. Although those error codes unmistakably remark a di