[ python-Bugs-1629369 ] email._parseaddr AddrlistClass bug
Bugs item #1629369, was opened at 2007-01-06 12:31
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1629369&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: Python Library
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Tokio Kikuchi (tkikuchi)
Assigned to: Nobody/Anonymous (nobody)
Summary: email._parseaddr AddrlistClass bug
Initial Comment:
email._parseaddr AddrlistClass incorrectly parse multilined comment (display
name).
According to RFC2822, folding white space is allowed in display name. Thus
following header should be parsed as a single address "[EMAIL PROTECTED]"
having multilined display name.
To: Foo
Bar <[EMAIL PROTECTED]>
On the other hand, following program results in:
from email.Utils import getaddresses
s = """Foo
Bar <[EMAIL PROTECTED]>
"""
print getaddresses([s])
[('', 'Foo'), ('Bar', '[EMAIL PROTECTED]')]
Note that the first address is not valid one.
Looks like the bug is in _parseaddr.py. Please check the patch.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1629369&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1629369 ] email._parseaddr AddrlistClass bug
Bugs item #1629369, was opened at 2007-01-06 12:31
Message generated for change (Settings changed) made by tkikuchi
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1629369&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: Python Library
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Tokio Kikuchi (tkikuchi)
>Assigned to: Barry A. Warsaw (bwarsaw)
Summary: email._parseaddr AddrlistClass bug
Initial Comment:
email._parseaddr AddrlistClass incorrectly parse multilined comment (display
name).
According to RFC2822, folding white space is allowed in display name. Thus
following header should be parsed as a single address "[EMAIL PROTECTED]"
having multilined display name.
To: Foo
Bar <[EMAIL PROTECTED]>
On the other hand, following program results in:
from email.Utils import getaddresses
s = """Foo
Bar <[EMAIL PROTECTED]>
"""
print getaddresses([s])
[('', 'Foo'), ('Bar', '[EMAIL PROTECTED]')]
Note that the first address is not valid one.
Looks like the bug is in _parseaddr.py. Please check the patch.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1629369&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1599254 ] mailbox: other programs' messages can vanish without trace
Bugs item #1599254, was opened at 2006-11-19 16:03 Message generated for change (Comment added) made by baikie You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1599254&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: Python Library Group: Python 2.5 Status: Open Resolution: None Priority: 9 Private: No Submitted By: David Watson (baikie) Assigned to: A.M. Kuchling (akuchling) Summary: mailbox: other programs' messages can vanish without trace Initial Comment: The mailbox classes based on _singlefileMailbox (mbox, MMDF, Babyl) implement the flush() method by writing the new mailbox contents into a temporary file which is then renamed over the original. Unfortunately, if another program tries to deliver messages while mailbox.py is working, and uses only fcntl() locking, it will have the old file open and be blocked waiting for the lock to become available. Once mailbox.py has replaced the old file and closed it, making the lock available, the other program will write its messages into the now-deleted "old" file, consigning them to oblivion. I've caused Postfix on Linux to lose mail this way (although I did have to turn off its use of dot-locking to do so). A possible fix is attached. Instead of new_file being renamed, its contents are copied back to the original file. If file.truncate() is available, the mailbox is then truncated to size. Otherwise, if truncation is required, it's truncated to zero length beforehand by reopening self._path with mode wb+. In the latter case, there's a check to see if the mailbox was replaced while we weren't looking, but there's still a race condition. Any alternative ideas? Incidentally, this fixes a problem whereby Postfix wouldn't deliver to the replacement file as it had the execute bit set. -- >Comment By: David Watson (baikie) Date: 2007-01-06 15:24 Message: Logged In: YES user_id=1504904 Originator: YES Aack, yes, that should be _next_user_key. Attaching a fixed version. I've been thinking, though: flush() does in fact invalidate the keys on platforms without a file.truncate(), when the fcntl() lock is momentarily released afterwards. It seems hard to avoid this as, perversely, fcntl() locks are supposed to be released automatically on all file descriptors referring to the file whenever the process closes any one of them - even one the lock was never set on. So, code using mailbox.py such platforms could inadvertently be carrying keys across an unlocked period, which is not made safe by the update-toc patch (as it's only meant to avert disasters resulting from doing this *and* rebuilding the table of contents, *assuming* that another process hasn't deleted or rearranged messages). File Added: mailbox-update-toc-fixed.diff -- Comment By: A.M. Kuchling (akuchling) Date: 2007-01-05 19:51 Message: Logged In: YES user_id=11375 Originator: NO Question about mailbox-update-doc: the add() method still returns self._next_key - 1; should this be self._next_user_key - 1? The keys in _user_toc are the ones returned to external users of the mailbox, right? (A good test case would be to initialize _next_key to 0 and _next_user_key to a different value like 123456.) I'm still staring at the patch, trying to convince myself that it will help -- haven't spotted any problems, but this bug is making me nervous... -- Comment By: A.M. Kuchling (akuchling) Date: 2007-01-05 19:24 Message: Logged In: YES user_id=11375 Originator: NO As a step toward improving matters, I've attached the suggested doc patch (for both 25-maint and trunk). It encourages people to use Maildir :), explicitly states that modifications should be bracketed by lock(), and fixes the examples to match. It does not say that keys are invalidated by doing a flush(), because we're going to try to avoid the necessity for that. File Added: mailbox-docs.diff -- Comment By: A.M. Kuchling (akuchling) Date: 2006-12-20 19:48 Message: Logged In: YES user_id=11375 Originator: NO Committed length-checking.diff to trunk in rev. 53110. -- Comment By: David Watson (baikie) Date: 2006-12-20 19:19 Message: Logged In: YES user_id=1504904 Originator: YES File Added: mailbox-test-lock.diff -- Comment By: David Watson (baikie) Date: 2006-12-20 19:17 Message: Logged In: YES user_id=1504904 Originator: YES Yeah, I think that should definitely go in. ExternalClashError or a subclass sounds fine to
[ python-Bugs-1599254 ] mailbox: other programs' messages can vanish without trace
Bugs item #1599254, was opened at 2006-11-19 16:03 Message generated for change (Comment added) made by baikie You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1599254&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: Python Library Group: Python 2.5 Status: Open Resolution: None Priority: 9 Private: No Submitted By: David Watson (baikie) Assigned to: A.M. Kuchling (akuchling) Summary: mailbox: other programs' messages can vanish without trace Initial Comment: The mailbox classes based on _singlefileMailbox (mbox, MMDF, Babyl) implement the flush() method by writing the new mailbox contents into a temporary file which is then renamed over the original. Unfortunately, if another program tries to deliver messages while mailbox.py is working, and uses only fcntl() locking, it will have the old file open and be blocked waiting for the lock to become available. Once mailbox.py has replaced the old file and closed it, making the lock available, the other program will write its messages into the now-deleted "old" file, consigning them to oblivion. I've caused Postfix on Linux to lose mail this way (although I did have to turn off its use of dot-locking to do so). A possible fix is attached. Instead of new_file being renamed, its contents are copied back to the original file. If file.truncate() is available, the mailbox is then truncated to size. Otherwise, if truncation is required, it's truncated to zero length beforehand by reopening self._path with mode wb+. In the latter case, there's a check to see if the mailbox was replaced while we weren't looking, but there's still a race condition. Any alternative ideas? Incidentally, this fixes a problem whereby Postfix wouldn't deliver to the replacement file as it had the execute bit set. -- >Comment By: David Watson (baikie) Date: 2007-01-06 15:30 Message: Logged In: YES user_id=1504904 Originator: YES File Added: mailbox-copy-back-53287.diff -- Comment By: David Watson (baikie) Date: 2007-01-06 15:24 Message: Logged In: YES user_id=1504904 Originator: YES Aack, yes, that should be _next_user_key. Attaching a fixed version. I've been thinking, though: flush() does in fact invalidate the keys on platforms without a file.truncate(), when the fcntl() lock is momentarily released afterwards. It seems hard to avoid this as, perversely, fcntl() locks are supposed to be released automatically on all file descriptors referring to the file whenever the process closes any one of them - even one the lock was never set on. So, code using mailbox.py such platforms could inadvertently be carrying keys across an unlocked period, which is not made safe by the update-toc patch (as it's only meant to avert disasters resulting from doing this *and* rebuilding the table of contents, *assuming* that another process hasn't deleted or rearranged messages). File Added: mailbox-update-toc-fixed.diff -- Comment By: A.M. Kuchling (akuchling) Date: 2007-01-05 19:51 Message: Logged In: YES user_id=11375 Originator: NO Question about mailbox-update-doc: the add() method still returns self._next_key - 1; should this be self._next_user_key - 1? The keys in _user_toc are the ones returned to external users of the mailbox, right? (A good test case would be to initialize _next_key to 0 and _next_user_key to a different value like 123456.) I'm still staring at the patch, trying to convince myself that it will help -- haven't spotted any problems, but this bug is making me nervous... -- Comment By: A.M. Kuchling (akuchling) Date: 2007-01-05 19:24 Message: Logged In: YES user_id=11375 Originator: NO As a step toward improving matters, I've attached the suggested doc patch (for both 25-maint and trunk). It encourages people to use Maildir :), explicitly states that modifications should be bracketed by lock(), and fixes the examples to match. It does not say that keys are invalidated by doing a flush(), because we're going to try to avoid the necessity for that. File Added: mailbox-docs.diff -- Comment By: A.M. Kuchling (akuchling) Date: 2006-12-20 19:48 Message: Logged In: YES user_id=11375 Originator: NO Committed length-checking.diff to trunk in rev. 53110. -- Comment By: David Watson (baikie) Date: 2006-12-20 19:19 Message: Logged In: YES user_id=1504904 Originator: YES File Added: mailbox-test-lock.diff ---
[ python-Bugs-1599254 ] mailbox: other programs' messages can vanish without trace
Bugs item #1599254, was opened at 2006-11-19 16:03 Message generated for change (Comment added) made by baikie You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1599254&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: Python Library Group: Python 2.5 Status: Open Resolution: None Priority: 9 Private: No Submitted By: David Watson (baikie) Assigned to: A.M. Kuchling (akuchling) Summary: mailbox: other programs' messages can vanish without trace Initial Comment: The mailbox classes based on _singlefileMailbox (mbox, MMDF, Babyl) implement the flush() method by writing the new mailbox contents into a temporary file which is then renamed over the original. Unfortunately, if another program tries to deliver messages while mailbox.py is working, and uses only fcntl() locking, it will have the old file open and be blocked waiting for the lock to become available. Once mailbox.py has replaced the old file and closed it, making the lock available, the other program will write its messages into the now-deleted "old" file, consigning them to oblivion. I've caused Postfix on Linux to lose mail this way (although I did have to turn off its use of dot-locking to do so). A possible fix is attached. Instead of new_file being renamed, its contents are copied back to the original file. If file.truncate() is available, the mailbox is then truncated to size. Otherwise, if truncation is required, it's truncated to zero length beforehand by reopening self._path with mode wb+. In the latter case, there's a check to see if the mailbox was replaced while we weren't looking, but there's still a race condition. Any alternative ideas? Incidentally, this fixes a problem whereby Postfix wouldn't deliver to the replacement file as it had the execute bit set. -- >Comment By: David Watson (baikie) Date: 2007-01-06 19:57 Message: Logged In: YES user_id=1504904 Originator: YES Oops, length checking had made the first two lines of this patch redundant; update-toc applies OK with fuzz. File Added: mailbox-copy-back-new.diff -- Comment By: David Watson (baikie) Date: 2007-01-06 15:30 Message: Logged In: YES user_id=1504904 Originator: YES File Added: mailbox-copy-back-53287.diff -- Comment By: David Watson (baikie) Date: 2007-01-06 15:24 Message: Logged In: YES user_id=1504904 Originator: YES Aack, yes, that should be _next_user_key. Attaching a fixed version. I've been thinking, though: flush() does in fact invalidate the keys on platforms without a file.truncate(), when the fcntl() lock is momentarily released afterwards. It seems hard to avoid this as, perversely, fcntl() locks are supposed to be released automatically on all file descriptors referring to the file whenever the process closes any one of them - even one the lock was never set on. So, code using mailbox.py such platforms could inadvertently be carrying keys across an unlocked period, which is not made safe by the update-toc patch (as it's only meant to avert disasters resulting from doing this *and* rebuilding the table of contents, *assuming* that another process hasn't deleted or rearranged messages). File Added: mailbox-update-toc-fixed.diff -- Comment By: A.M. Kuchling (akuchling) Date: 2007-01-05 19:51 Message: Logged In: YES user_id=11375 Originator: NO Question about mailbox-update-doc: the add() method still returns self._next_key - 1; should this be self._next_user_key - 1? The keys in _user_toc are the ones returned to external users of the mailbox, right? (A good test case would be to initialize _next_key to 0 and _next_user_key to a different value like 123456.) I'm still staring at the patch, trying to convince myself that it will help -- haven't spotted any problems, but this bug is making me nervous... -- Comment By: A.M. Kuchling (akuchling) Date: 2007-01-05 19:24 Message: Logged In: YES user_id=11375 Originator: NO As a step toward improving matters, I've attached the suggested doc patch (for both 25-maint and trunk). It encourages people to use Maildir :), explicitly states that modifications should be bracketed by lock(), and fixes the examples to match. It does not say that keys are invalidated by doing a flush(), because we're going to try to avoid the necessity for that. File Added: mailbox-docs.diff -- Comment By: A.M. Kuchling (akuchling) Date: 2006-12-20 19:48 Message: Logged In: YES user_id=11375 Originator
[ python-Bugs-1627244 ] xml.dom.minidom parse bug
Bugs item #1627244, was opened at 2007-01-03 10:04
Message generated for change (Comment added) made by nnorwitz
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1627244&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: Python Library
Group: Python 2.4
Status: Closed
Resolution: Duplicate
Priority: 5
Private: No
Submitted By: Pierre Imbaud (pmi)
Assigned to: Nobody/Anonymous (nobody)
Summary: xml.dom.minidom parse bug
Initial Comment:
xml.dom.minidom was unable to parse an xml file that came from an example
provided by an official organism.(http://www.iptc.org/IPTC4XMP)
The parsed file was somewhat hairy, but I have been able to reproduce the bug
with a simplified
version, attached. (ends with .xmp: its supposed
to be an xmp file, the xmp standard being built on
xml. Well, thats the short story).
The offending part is the one that goes: xmpPLUS=''
it triggers an exception: ValueError: too many values to unpack,
in _parse_ns_name. Some debugging showed an obvious mistake
in the scanning of the name argument, that goes beyond the closing
" ' ".
I digged a little further thru a pdb session, but the bug seems to be located
in c code.
Thats the very first time I report a bug, chances are I provide too much or too
little information...
To whoever it may concern, here is the invoking code:
from xml.dom import minidom
...
class xmp(dict):
def __init__(self, inStream):
xmldoc = minidom.parse(inStream)
x = xmp('/home/pierre/devt/port/IPTCCore-Full/x.xmp')
traceback:
/home/pierre/devt/fileInfo/svnRep/branches/xml/xmpLib/xmpLib.py in
__init__(self, inStream)
26 def __init__(self, inStream):
27 print minidom
---> 28 xmldoc = minidom.parse(inStream)
29 xmpmeta = xmldoc.childNodes[1]
30 rdf = xmpmeta.childNodes[1]
/home/pierre/devt/fileInfo/svnRep/branches/xml/xmpLib/nxml/dom/minidom.py in
parse(file, parser, bufsize)
/home/pierre/devt/fileInfo/svnRep/branches/xml/xmpLib/xml/dom/expatbuilder.py
in parse(file, namespaces)
922 fp = open(file, 'rb')
923 try:
--> 924 result = builder.parseFile(fp)
925 finally:
926 fp.close()
/home/pierre/devt/fileInfo/svnRep/branches/xml/xmpLib/xml/dom/expatbuilder.py
in parseFile(self, file)
205 if not buffer:
206 break
--> 207 parser.Parse(buffer, 0)
208 if first_buffer and self.document.documentElement:
209 self._setup_subset(buffer)
/home/pierre/devt/fileInfo/svnRep/branches/xml/xmpLib/xml/dom/expatbuilder.py
in start_element_handler(self, name, attributes)
743 def start_element_handler(self, name, attributes):
744 if ' ' in name:
--> 745 uri, localname, prefix, qname = _parse_ns_name(self, name)
746 else:
747 uri = EMPTY_NAMESPACE
/home/pierre/devt/fileInfo/svnRep/branches/xml/xmpLib/xml/dom/expatbuilder.py
in _parse_ns_name(builder, name)
125 localname = intern(localname, localname)
126 else:
--> 127 uri, localname = parts
128 prefix = EMPTY_PREFIX
129 qname = localname = intern(localname, localname)
ValueError: too many values to unpack
The offending c statement:
/usr/src/packages/BUILD/Python-2.4/Modules/pyexpat.c(582)StartElement()
The returned 'name':
(Pdb) name
Out[5]: u'XMP Photographic Licensing Universal System (xmpPLUS,
http://ns.adobe.com/xap/1.0/PLUS/) CreditLineReq xmpPLUS'
Its obvious the scanning went beyond the attribute.
--
>Comment By: Neal Norwitz (nnorwitz)
Date: 2007-01-06 13:19
Message:
Logged In: YES
user_id=33168
Originator: NO
Dupe of 1627096
--
Comment By: Neal Norwitz (nnorwitz)
Date: 2007-01-03 22:32
Message:
Logged In: YES
user_id=33168
Originator: NO
Dupe of 1627096
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1627244&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1623890 ] module docstring for subprocess is wrong
Bugs item #1623890, was opened at 2006-12-28 13:49 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1623890&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: Python Library Group: Python 2.5 Status: Closed Resolution: Fixed Priority: 5 Private: No Submitted By: Neal Norwitz (nnorwitz) Assigned to: Neal Norwitz (nnorwitz) Summary: module docstring for subprocess is wrong Initial Comment: The module docstring for subprocess is wrong. It says: communicate(input=None) Interact with process: Send data to stdin. Read data from stdout and stderr, until end-of-file is reached. Wait for process to terminate. The optional stdin argument should be a string to be sent to the child process, or None, if no data should be sent to the child. I'm not sure how to word the first stdin, but the second one should definitely be input, not stdin. Also need to verify the docstring for the communicate method. I'm guessing this affects Python 2.4 and later. Looking at 2.4.1? right now. -- >Comment By: Neal Norwitz (nnorwitz) Date: 2007-01-06 13:19 Message: Logged In: YES user_id=33168 Originator: YES Committed revision 53187. (2.5) Committed revision 53188. -- Comment By: Neal Norwitz (nnorwitz) Date: 2006-12-28 19:02 Message: Logged In: YES user_id=33168 Originator: YES Committed revision 53187. (2.5) Committed revision 53188. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1623890&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1545837 ] array.array borks on deepcopy
Bugs item #1545837, was opened at 2006-08-24 02:49
Message generated for change (Comment added) made by nnorwitz
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1545837&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: Python Library
Group: Python 2.5
>Status: Open
>Resolution: Accepted
Priority: 9
Private: No
Submitted By: Václav Haisman (wilx)
>Assigned to: Neal Norwitz (nnorwitz)
Summary: array.array borks on deepcopy
Initial Comment:
Hi,
I think there is a bug arraymodule.c this line:
{"__deepcopy__",(PyCFunction)array_copy,METH_NOARGS,
copy_doc},
should probably have METH_O instead of METH_NOARGS
there, since according to docs and the prototype of the
array_copy() function there is one parameter.
--
>Comment By: Neal Norwitz (nnorwitz)
Date: 2007-01-06 13:19
Message:
Logged In: YES
user_id=33168
Originator: NO
Thomas, was there any reason this wasn't checked in to 2.5? I'm guessing
it was just forgotten. I don't see any mention in Misc/NEWS either.
--
Comment By: Thomas Wouters (twouters)
Date: 2006-12-29 07:05
Message:
Logged In: YES
user_id=34209
Originator: NO
Backported.
--
Comment By: Thomas Wouters (twouters)
Date: 2006-12-28 01:11
Message:
Logged In: YES
user_id=34209
Originator: NO
The 2.5 branch at the time was still pre-2.5.0, and we didn't want to make
this change between release candidate and release. It's safe to be checked
into release25-maint now. I'll do it sometime tonight.
--
Comment By: Neal Norwitz (nnorwitz)
Date: 2006-12-27 23:59
Message:
Logged In: YES
user_id=33168
Originator: NO
Thomas, was there any reason this wasn't checked in to 2.5? I'm guessing
it was just forgotten. I don't see any mention in Misc/NEWS either.
--
Comment By: Thomas Wouters (twouters)
Date: 2006-08-29 00:35
Message:
Logged In: YES
user_id=34209
Not unless you want another release candidate. copy.deepcopy
has never worked on array instances, so it's not a
release-preventing bug (but each bugfix may *add* a
release-preventing bug by accident :)
--
Comment By: Raymond Hettinger (rhettinger)
Date: 2006-08-28 06:32
Message:
Logged In: YES
user_id=80475
Should this be fixed in the release candidate?
--
Comment By: Thomas Wouters (twouters)
Date: 2006-08-24 11:50
Message:
Logged In: YES
user_id=34209
Thanks! Fixed in the trunk (which is 2.6-to-be) revision
51565, and it will also be fixed for Python 2.4.4 and 2.5.1.
It's unfortunately just a bit too late for 2.5.0.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1545837&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1545837 ] array.array borks on deepcopy
Bugs item #1545837, was opened at 2006-08-24 02:49
Message generated for change (Comment added) made by nnorwitz
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1545837&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: Python Library
Group: Python 2.5
>Status: Closed
>Resolution: Fixed
Priority: 9
Private: No
Submitted By: Václav Haisman (wilx)
>Assigned to: Thomas Wouters (twouters)
Summary: array.array borks on deepcopy
Initial Comment:
Hi,
I think there is a bug arraymodule.c this line:
{"__deepcopy__",(PyCFunction)array_copy,METH_NOARGS,
copy_doc},
should probably have METH_O instead of METH_NOARGS
there, since according to docs and the prototype of the
array_copy() function there is one parameter.
--
>Comment By: Neal Norwitz (nnorwitz)
Date: 2007-01-06 13:21
Message:
Logged In: YES
user_id=33168
Originator: NO
Stupid SF.
--
Comment By: Neal Norwitz (nnorwitz)
Date: 2007-01-06 13:19
Message:
Logged In: YES
user_id=33168
Originator: NO
Thomas, was there any reason this wasn't checked in to 2.5? I'm guessing
it was just forgotten. I don't see any mention in Misc/NEWS either.
--
Comment By: Thomas Wouters (twouters)
Date: 2006-12-29 07:05
Message:
Logged In: YES
user_id=34209
Originator: NO
Backported.
--
Comment By: Thomas Wouters (twouters)
Date: 2006-12-28 01:11
Message:
Logged In: YES
user_id=34209
Originator: NO
The 2.5 branch at the time was still pre-2.5.0, and we didn't want to make
this change between release candidate and release. It's safe to be checked
into release25-maint now. I'll do it sometime tonight.
--
Comment By: Neal Norwitz (nnorwitz)
Date: 2006-12-27 23:59
Message:
Logged In: YES
user_id=33168
Originator: NO
Thomas, was there any reason this wasn't checked in to 2.5? I'm guessing
it was just forgotten. I don't see any mention in Misc/NEWS either.
--
Comment By: Thomas Wouters (twouters)
Date: 2006-08-29 00:35
Message:
Logged In: YES
user_id=34209
Not unless you want another release candidate. copy.deepcopy
has never worked on array instances, so it's not a
release-preventing bug (but each bugfix may *add* a
release-preventing bug by accident :)
--
Comment By: Raymond Hettinger (rhettinger)
Date: 2006-08-28 06:32
Message:
Logged In: YES
user_id=80475
Should this be fixed in the release candidate?
--
Comment By: Thomas Wouters (twouters)
Date: 2006-08-24 11:50
Message:
Logged In: YES
user_id=34209
Thanks! Fixed in the trunk (which is 2.6-to-be) revision
51565, and it will also be fixed for Python 2.4.4 and 2.5.1.
It's unfortunately just a bit too late for 2.5.0.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1545837&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1629566 ] documentation of email.utils.parsedate is confusing
Bugs item #1629566, was opened at 2007-01-06 15:37 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1629566&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: Documentation Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Nicholas Riley (nriley) Assigned to: Nobody/Anonymous (nobody) Summary: documentation of email.utils.parsedate is confusing Initial Comment: This sentence in the documentation for email.utils.parsedate confused me: "Note that fields 6, 7, and 8 of the result tuple are not usable." These indices are zero-based, so it's actually fields 7, 8 and 9 that they are talking about (in normal English). Either this should be changed to 7-9 or be re-expressed in a way that makes it clear it's zero-based, for example by using Python indexing notation. Thanks. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1629566&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-889153 ] asyncore.dispactcher: incorrect connect
Bugs item #889153, was opened at 2004-02-02 11:04 Message generated for change (Settings changed) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=889153&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: Python Library Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Sankov Dmitry Alexandrovich (sankov_da) >Assigned to: Josiah Carlson (josiahcarlson) Summary: asyncore.dispactcher: incorrect connect Initial Comment: When i use non-blocking socket, connect() method of asyncore.dispatcher class looks like works incorrect. Example: if connection have not established then socket merely closed and handle_error not called and no exception throwed. One more example: if writable() and readble() methods returns zero than handle_connect() will never be called even if connection will be established. Thanks. -- Comment By: Alexey Klimkin (klimkin) Date: 2004-03-04 03:22 Message: Logged In: YES user_id=410460 Patch #909005 fixes the problem. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=889153&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-760475 ] asyncore.py and "handle_error"
Bugs item #760475, was opened at 2003-06-25 09:11 Message generated for change (Settings changed) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=760475&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: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Jes�s Cea Avi�n (jcea) >Assigned to: Josiah Carlson (josiahcarlson) Summary: asyncore.py and "handle_error" Initial Comment: When an uncached exception arises in "asyncore", the method "handle_error" is called. This method calls "self.close()" when it MUST call "self.handle_close()", in order to support correctly the "delegation" design pattern, for example. -- Comment By: Jeremy Hylton (jhylton) Date: 2003-06-25 14:11 Message: Logged In: YES user_id=31392 Can you expand on your comments. I don't know what the delegation design pattern you refer to is. Can you provide an example of why it is necessary that asyncore not call close()? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=760475&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-539444 ] asyncore file wrapper & os.error
Bugs item #539444, was opened at 2002-04-04 15:57 Message generated for change (Settings changed) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=539444&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: Python Library Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Jeremy Hylton (jhylton) >Assigned to: Josiah Carlson (josiahcarlson) Summary: asyncore file wrapper & os.error Initial Comment: The file wrapper makes a file descriptor look like an asycnore socket. When its recv() method is invoked, it calls os.read(). I use this in an application where os.read() occasionally raises os.error (11, 'Resource temporarily unavailable'). I think that asyncore should catch this error and treat it just like EWOULDBLOCK. But I'd like a second opinion. -- Comment By: Martin v. Löwis (loewis) Date: 2002-04-07 05:03 Message: Logged In: YES user_id=21627 I'm still uncertain what precisely was happening here. What system was this on? On many systems, EAGAIN is EWOULDBLOCK; if that is the case, adding EAGAIN to the places that currently handle EWOULDBLOCK won't change anything. -- Comment By: Jeremy Hylton (jhylton) Date: 2002-04-05 11:44 Message: Logged In: YES user_id=31392 It happens when the file is a pipe. For details, see the ZEO bug report at https://sourceforge.net/tracker/index.php? func=detail&aid=536416&group_id=15628&atid=115628 I've included the traceback from that bug report, too. error: uncaptured python exception, closing channel(exceptions.OSError:[Errno 11] Resource temporarily unavailable [/home/zope/opt/Python- 2.1.2/lib/python2.1/asyncore.py|poll|92] [/home/zope/opt/Python- 2.1.2/lib/python2.1/asyncore.py|handle_read_event|386] [/home/zope/opt/Python-2.1.2/lib/python2.1/site- packages/ZEO/trigger.py|handle_read|95] [/home/zope/opt/Python- 2.1.2/lib/python2.1/asyncore.py|recv|338] [/home/zope/opt/Python- 2.1.2/lib/python2.1/asyncore.py|recv|520]) Exception exceptions.OSError: (9, 'Bad file descriptor') in ignored -- Comment By: Martin v. Löwis (loewis) Date: 2002-04-05 04:00 Message: Logged In: YES user_id=21627 Can you report details of the file that returns EWOULDBLOCK? This is not supposed to happen in applications of the file_wrapper. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=539444&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-953599 ] asyncore misses socket closes when poll is used
Bugs item #953599, was opened at 2004-05-13 17:47 Message generated for change (Settings changed) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=953599&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: Python Library Group: None Status: Open Resolution: None Priority: 6 Private: No Submitted By: Shane Kerr (shane_kerr) >Assigned to: Josiah Carlson (josiahcarlson) Summary: asyncore misses socket closes when poll is used Initial Comment: Problem: If the loop() function of asyncore is invoked with poll rather than select, the function readwrite() is used when I/O is available on a socket. However, this function does not check for hangup - provided by POLLHUP. If a socket is attempting to write, then POLLOUT never gets set, so the socket hangs. Because poll() is returning immediately, but the return value is never used, asyncore busy-loops, consuming all available CPU. Possible solutions: The easy solution is to check for POLLHUP in the readwrite() function: if flags & (select.POLLOUT | select.POLLHUP): obj.handle_write_event() This makes the poll work exactly like the select - the application raises a socket.error set to EPIPE. An alternate solution - possibly more graceful - is to invoke the handle_close() method of the object: if flags & select.POLLHUP: obj.handle_close() else: if flags & select.POLLIN: obj.handle_read_event() if flags & select.pollout: obj.handle_write_event() This is incompatible with the select model, but it means that the read and write logic is now the same for socket hangups - handle_close() is invoked. -- Comment By: Alexey Klimkin (klimkin) Date: 2004-07-02 09:56 Message: Logged In: YES user_id=410460 Perhaps, it would be better to raise exception: def readwrite(obj, flags): try: if flags & (select.POLLIN | select.POLLPRI): obj.handle_read_event() if flags & select.POLLOUT: obj.handle_write_event() if flags & (select.POLLERR | select.POLLHUP | select.POLLNVAL): obj.handle_expt_event() except ExitNow: raise except: obj.handle_error() ... def handle_expt_event(self): err = self.socket.getsockopt(socket.SOL_SOCKET, socket.SO_ERROR) assert(err != 0) raise socket.error, (err, errorcode[err]) Since asyncore closes socket in handle_error, this solves the problem too. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=953599&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1161031 ] Neverending warnings from asyncore
Bugs item #1161031, was opened at 2005-03-10 19:34 Message generated for change (Settings changed) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1161031&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: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Tony Meyer (anadelonbrin) >Assigned to: Josiah Carlson (josiahcarlson) Summary: Neverending warnings from asyncore Initial Comment: Changes in asyncore from 2.3 to 2.4 mean that asyncore.poll() now passes all the sockets in the map to select.select() to be checked for errors, which is probably a good thing. If an error occurs, then handle_expt() is called, which by default logs the error. asyncore.dispatcher creates nonblocking sockets. When connect_ex() is called on a nonblocking socket, it will probably return EWOULDBLOCK (connecting takes time), which may mean the connection is successful, or may not (asyncore dispatcher keeps going assuming all is well). If the connection is not successful, and then asyncore.loop() is called, then select.select() will indicate that there is an error with the socket (can't connect) and the error will be logged. The trouble is that asyncore.loop then keeps going, and will log this error again. My not-that-fast system here gets about 10,000 logged messages per second with a single socket in the asyncore map. There are ways to avoid this: (1) if the socket is blocking when connect()ing (and then nonblocking afterwards) an error is raised if the connect fails. (2) Before calling asyncore.loop(), the caller can run through all the sockets, checking that they are ok. (3) handle_expt() can be overridden with a function that repairs or removes the socket from the map (etc) However, I'm not convinced that this is good behavior for asyncore to have, by default. On Windows, select.select() will only indicate an error when trying to connect (nonblocking) or if SO_OOBINLINE is disabled, but this may not be the case (i.e. errors can occur at other times) with other platforms, right? Unless the error is temporary, asyncore will by default start streaming (extremely fast) a lot of "warning: unhandled exception" (not very helpful an error message, either) messages. Even if the error only lasts a minute, that could easily result in 10,000 warnings being logged. Do any of the python developers agree that this is a flaw? I'm happy to work up a patch for whatever the desired solution is, if so. -- Comment By: Tim Peters (tim_one) Date: 2005-06-09 12:11 Message: Logged In: YES user_id=31435 My guess is rev 1.57. -- Comment By: A.M. Kuchling (akuchling) Date: 2005-06-09 11:41 Message: Logged In: YES user_id=11375 What change to asyncore caused the problem? -- Comment By: Tim Peters (tim_one) Date: 2005-06-02 22:02 Message: Logged In: YES user_id=31435 I agree the change in default behavior here was at least questionable, and spent more than a week of my own "dealing with consequences" of 2.4 asyncore changes in ZODB and Zope. Assigning to Andrew, since it looks like he made the change in question here. Andrew, why did this change? How can it be improved? I don't think Tony has mentioned it here, but when SpamBayes was first released with Python 2.4, it was a disaster because some users found their hard drives literally filled with gigabytes of mysterious "warning: unhandled exception" messages. -- Comment By: Tony Meyer (anadelonbrin) Date: 2005-06-02 21:38 Message: Logged In: YES user_id=552329 I am not at all unwilling (and this isn't a problem for me personally - the issue here is whether this is good for Python in general) to subclass. Deciding to subclass does *not* mean that you should have to replace all functions in the parent class. If you did, then there would be little point in subclassing at all. Sensible default behaviour should be provided as methods of classes. The current behaviour of the handle_expt() method is not sensible. It essentially forces the user to override that method, even if they have no interest in handling errors (e.g. and would normally just override handle_read and handle_write). This is *not* rare. You haven't seen any in years, because this was a change introduced in Python 2.4, which hasn't been released for even one year yet. I agree that the desired behaviour will be application specific. But what is the point of having default behaviour that will essentially crash the program/system running it? Having default behaviour be "pa
[ python-Bugs-658749 ] asyncore connect() and winsock errors
Bugs item #658749, was opened at 2002-12-26 13:25 Message generated for change (Settings changed) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=658749&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: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Guido van Rossum (gvanrossum) >Assigned to: Josiah Carlson (josiahcarlson) Summary: asyncore connect() and winsock errors Initial Comment: asyncore's connect() method should interpret the winsock errors; these are different from Unix (and different between the Win98 family and the Win2k family). -- Comment By: Alexey Klimkin (klimkin) Date: 2004-03-04 03:24 Message: Logged In: YES user_id=410460 Patch #909005 fixes the problem. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=658749&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-654766 ] asyncore.py and "handle_expt"
Bugs item #654766, was opened at 2002-12-16 13:42
Message generated for change (Settings changed) made by akuchling
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=654766&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: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Jes�s Cea Avi�n (jcea)
>Assigned to: Josiah Carlson (josiahcarlson)
Summary: asyncore.py and "handle_expt"
Initial Comment:
Python 2.2.2 here.
Asyncore.py doesn't invoke "handle_expt" ever
("handle_expt" is documented in docs). Managing OOB
data is imprescindible to handle "connection refused"
errors in Windows, for example.
--
Comment By: Alexey Klimkin (klimkin)
Date: 2004-03-04 03:24
Message:
Logged In: YES
user_id=410460
Patch #909005 fixes the problem.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=654766&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1063924 ] asyncore should handle ECONNRESET in send
Bugs item #1063924, was opened at 2004-11-10 11:27 Message generated for change (Settings changed) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1063924&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: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Florent Guillaume (efge) >Assigned to: Josiah Carlson (josiahcarlson) Summary: asyncore should handle ECONNRESET in send Initial Comment: asyncore.dispatcher.send doesn't handle ECONNRESET, whereas recv correctly does. When such an error occurs, Zope displays for instance: ERROR(200) ZServer uncaptured python exception, closing channel (socket.error:(104, 'Connection reset by peer') [/usr/local/lib/python2.3/asynchat.py|initiate_send|218] [/usr/local/zope/2.7.2/lib/python/ZServer/medusa/http_server.py|send|417] [/usr/local/lib/python2.3/asyncore.py|send|337]) zhttp_channel is just a subclass of http_channel. The exception is raised by asyncore itself when it receives the unhandled error. A proposed fix would be to do the same kind of handling than is done in recv, but I don't know enough about asyncore to know if it's correct -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1063924&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-777588 ] asyncore is broken for windows if connection is refused
Bugs item #777588, was opened at 2003-07-25 10:43 Message generated for change (Settings changed) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=777588&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: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Garth Bushell (garth42) >Assigned to: Josiah Carlson (josiahcarlson) Summary: asyncore is broken for windows if connection is refused Initial Comment: asyncore.poll is broken on windows. If a connection is refused happens it will hang for ever and never raise an exception. The Select statment never checks the exfds. This is needed as this is where windows reports failed connections. The documentation in the microsoft platform SDK mentions this. http://msdn.microsoft.com/library/default.asp?url=/library/en-us/winsock/winsock/select_2.asp The suggested fix is shown below althought this is untested. The correct error number is recived from getsockopt(SOL_SOCKET,SO_ERROR) def poll(timeout=0.0, map=None): if map is None: map = socket_map if map: r = []; w = []; e = [] for fd, obj in map.items(): if obj.readable(): r.append(fd) if obj.writable(): w.append(fd) if sys.platform == 'win32': if not obj.connected: e.append(fd) if [] == r == w == e: time.sleep(timeout) else: try: r, w, e = select.select(r, w, e, timeout) except select.error, err: if err[0] != EINTR: raise else: return if sys.platform == 'win32': for fd in e: obj = map.get(fd) if obj is None: continue errno = fs.getsockopt(socket.SOL_SOCKET, socket.SO_ERROR) raise socket.error,(errno,socketerrorTab[error]) for fd in r: obj = map.get(fd) if obj is None: continue read(obj) for fd in w: obj = map.get(fd) if obj is None: continue write(obj) -- Comment By: Alexey Klimkin (klimkin) Date: 2004-03-04 03:23 Message: Logged In: YES user_id=410460 Patch #909005 fixes the problem. -- Comment By: John J Smith (johnjsmith) Date: 2003-07-29 08:49 Message: Logged In: YES user_id=830565 I was bitten by the same problem. My workaround (in a Tkinter application) is given below. Would it make sense to modify poll() to simply add the union of r and w to e, and call handle_error() for any fd in e? Workaround: try: self.connect(send_addr) except socket.error: self.handle_error() if sys.platform == 'win32': # Win98 select() doesn't seem to report errors for a # non-blocking connect(). self.__connected = 0 self.__frame.after(2000, self.__win_connect_poll) ... if sys.platform == 'win32': def __win_connect_poll (self): if self.__connected: return e = self.socket.getsockopt(socket.SOL_SOCKET, socket.SO_ERROR) if e in (0, errno.EINPROGRESS, errno.WSAEINPROGRESS): self.__frame.after(2000, self.__win_connect_poll) else: try: str = socket.errorTab[e] except KeyError: str = os.strerror(e) try: raise socket.error(e, str) except socket.error: self.handle_error() -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=777588&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1025525 ] asyncore.file_dispatcher should not take fd as argument
Bugs item #1025525, was opened at 2004-09-09 22:14 Message generated for change (Settings changed) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1025525&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: Python Library Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: david houlder (dhoulder) >Assigned to: Josiah Carlson (josiahcarlson) Summary: asyncore.file_dispatcher should not take fd as argument Initial Comment: Only relevant to posix. asyncore.file_dispatcher closes the file descriptor behind the file object, and not the file object itself. When another file gets opened, it gets the next available fd, which on posix, is the one just released by the close. Tested on python 2.2.3 on RedHat Enterprise Linux 3 and python 2.2.1 on HP Tru64 unix. See attached script for details and a solution. 'case 1' should show the problem regardless of the garbage collection strategy in python. 'case 2' relies on the file object being closed as soon as the last reference to it disappears, which seems to be the (current?) behaviour. [EMAIL PROTECTED] djh900]$ python file_dispatcher_bug.py case 1: (Read 'I am the first pipe\n' from pipe) (pipe closing. fd== 3 ) (Read '' from pipe) firstPipe.read() says 'I am the second pipe\n' firstPipe.fileno()== 3 secondPipe.fileno()== 3 case 2: (Read 'I am the first pipe\n' from pipe) (pipe closing. fd== 3 ) (Read '' from pipe) secondPipe.fileno()== 3 dispatcher.secondPipe.read() says Traceback (most recent call last): File "file_dispatcher_bug.py", line 77, in ? print "dispatcher.secondPipe.read() says", repr(dispatcher.secondPipe.read()) IOError: [Errno 9] Bad file descriptor [EMAIL PROTECTED] djh900]$ -- Comment By: david houlder (dhoulder) Date: 2004-11-17 18:43 Message: Logged In: YES user_id=1119185 In an ideal world I'd propose replacing the guts of file_wrapper() and file_dispatcher() by my pipe_wrapper() and PipeDispatcher(), since the general problem of closing the file descriptor behind the python object applies to all python objects that are based on a file descriptor, not just pipes. So, yes, probably best not to call it pipe_dispatcher(). And I guess file_dispatcher() may be in use by other peoples' code and changing it to take a file object rather than an fd will break that. Maybe file_dispatcher.__init__() could be changed to take either an integer file descriptor or a file object as it's argument, and behave like the current file_dispatcher() when given an fd, and like pipe_dispatcher() when given a file-like object (i.e. any object with fileno() and close() methods will probably be enough). I'm happy to whip up an example if people think that's a good idea. -- Comment By: Jeremy Hylton (jhylton) Date: 2004-11-07 10:23 Message: Logged In: YES user_id=31392 I'm not sure whether you propose a change to asyncore or are describing a pattern that allows you to use a pipe with it safely. And, looking at your code more closely, I think pipe is confusing, because you're not talking about os.pipe() right? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1025525&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1025525 ] asyncore.file_dispatcher should not take fd as argument
Bugs item #1025525, was opened at 2004-09-09 19:14 Message generated for change (Comment added) made by josiahcarlson You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1025525&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: Python Library Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: david houlder (dhoulder) Assigned to: Josiah Carlson (josiahcarlson) Summary: asyncore.file_dispatcher should not take fd as argument Initial Comment: Only relevant to posix. asyncore.file_dispatcher closes the file descriptor behind the file object, and not the file object itself. When another file gets opened, it gets the next available fd, which on posix, is the one just released by the close. Tested on python 2.2.3 on RedHat Enterprise Linux 3 and python 2.2.1 on HP Tru64 unix. See attached script for details and a solution. 'case 1' should show the problem regardless of the garbage collection strategy in python. 'case 2' relies on the file object being closed as soon as the last reference to it disappears, which seems to be the (current?) behaviour. [EMAIL PROTECTED] djh900]$ python file_dispatcher_bug.py case 1: (Read 'I am the first pipe\n' from pipe) (pipe closing. fd== 3 ) (Read '' from pipe) firstPipe.read() says 'I am the second pipe\n' firstPipe.fileno()== 3 secondPipe.fileno()== 3 case 2: (Read 'I am the first pipe\n' from pipe) (pipe closing. fd== 3 ) (Read '' from pipe) secondPipe.fileno()== 3 dispatcher.secondPipe.read() says Traceback (most recent call last): File "file_dispatcher_bug.py", line 77, in ? print "dispatcher.secondPipe.read() says", repr(dispatcher.secondPipe.read()) IOError: [Errno 9] Bad file descriptor [EMAIL PROTECTED] djh900]$ -- >Comment By: Josiah Carlson (josiahcarlson) Date: 2007-01-06 14:48 Message: Logged In: YES user_id=341410 Originator: NO I believe that asyncore.file_dispatcher taking a file descriptor is fine. The problem is that the documentation doesn't suggest that you os.dup() the file handle so that both the original handle (from a pipe, file, etc.) can be closed independently from the one being used by the file_dispatcher. In the case of socket.makefile(), the duplication is done automatically, so there isn't the same problem. My suggested fix would be to accept a file or a file handle. For files, we first get its file number via the standard f.fileno(), and with that, or the handle we are provided, we os.dup() the handle. -- Comment By: david houlder (dhoulder) Date: 2004-11-17 15:43 Message: Logged In: YES user_id=1119185 In an ideal world I'd propose replacing the guts of file_wrapper() and file_dispatcher() by my pipe_wrapper() and PipeDispatcher(), since the general problem of closing the file descriptor behind the python object applies to all python objects that are based on a file descriptor, not just pipes. So, yes, probably best not to call it pipe_dispatcher(). And I guess file_dispatcher() may be in use by other peoples' code and changing it to take a file object rather than an fd will break that. Maybe file_dispatcher.__init__() could be changed to take either an integer file descriptor or a file object as it's argument, and behave like the current file_dispatcher() when given an fd, and like pipe_dispatcher() when given a file-like object (i.e. any object with fileno() and close() methods will probably be enough). I'm happy to whip up an example if people think that's a good idea. -- Comment By: Jeremy Hylton (jhylton) Date: 2004-11-07 07:23 Message: Logged In: YES user_id=31392 I'm not sure whether you propose a change to asyncore or are describing a pattern that allows you to use a pipe with it safely. And, looking at your code more closely, I think pipe is confusing, because you're not talking about os.pipe() right? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1025525&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-760475 ] asyncore.py and "handle_error"
Bugs item #760475, was opened at 2003-06-25 06:11 Message generated for change (Comment added) made by josiahcarlson You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=760475&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: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Jes�s Cea Avi�n (jcea) Assigned to: Josiah Carlson (josiahcarlson) Summary: asyncore.py and "handle_error" Initial Comment: When an uncached exception arises in "asyncore", the method "handle_error" is called. This method calls "self.close()" when it MUST call "self.handle_close()", in order to support correctly the "delegation" design pattern, for example. -- >Comment By: Josiah Carlson (josiahcarlson) Date: 2007-01-06 15:02 Message: Logged In: YES user_id=341410 Originator: NO While the default .close() method is called inside .handle_close(), not calling .handle_close() in asyncore prevents any subclassed .handle_close() behavior to be run. Say, for example, that a user has written a subclass where within .handle_connect() the socket is registered somewhere (perhaps for I/O statistics in an FTP or Bittorrent application). Where it would make sense to place the unregistration code is within a .handle_close() method, which is bypassed by the standard .handle_error() code. I suggest switching to the self.handle_close() call at the end of handle_error() . Doing so preserves the passing of the test suite on release 2.5 on Windows. -- Comment By: Jeremy Hylton (jhylton) Date: 2003-06-25 11:11 Message: Logged In: YES user_id=31392 Can you expand on your comments. I don't know what the delegation design pattern you refer to is. Can you provide an example of why it is necessary that asyncore not call close()? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=760475&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-889153 ] asyncore.dispactcher: incorrect connect
Bugs item #889153, was opened at 2004-02-02 08:04 Message generated for change (Comment added) made by josiahcarlson You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=889153&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: Python Library Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Sankov Dmitry Alexandrovich (sankov_da) Assigned to: Josiah Carlson (josiahcarlson) Summary: asyncore.dispactcher: incorrect connect Initial Comment: When i use non-blocking socket, connect() method of asyncore.dispatcher class looks like works incorrect. Example: if connection have not established then socket merely closed and handle_error not called and no exception throwed. One more example: if writable() and readble() methods returns zero than handle_connect() will never be called even if connection will be established. Thanks. -- >Comment By: Josiah Carlson (josiahcarlson) Date: 2007-01-06 15:05 Message: Logged In: YES user_id=341410 Originator: NO It sounds as though the original poster is passing a socket that has been created, but which is not yet connected, to the dispatcher constructor. We should update the documentation to state that either the user should pass a completely connected socket (as returned by socket.accept(), or which has connected as the result of a a blocking socket.connect() call), or use the .create_socket() and .connect() methods of the dispatcher. -- Comment By: Alexey Klimkin (klimkin) Date: 2004-03-04 00:22 Message: Logged In: YES user_id=410460 Patch #909005 fixes the problem. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=889153&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1161031 ] Neverending warnings from asyncore
Bugs item #1161031, was opened at 2005-03-10 16:34 Message generated for change (Comment added) made by josiahcarlson You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1161031&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: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Tony Meyer (anadelonbrin) >Assigned to: A.M. Kuchling (akuchling) Summary: Neverending warnings from asyncore Initial Comment: Changes in asyncore from 2.3 to 2.4 mean that asyncore.poll() now passes all the sockets in the map to select.select() to be checked for errors, which is probably a good thing. If an error occurs, then handle_expt() is called, which by default logs the error. asyncore.dispatcher creates nonblocking sockets. When connect_ex() is called on a nonblocking socket, it will probably return EWOULDBLOCK (connecting takes time), which may mean the connection is successful, or may not (asyncore dispatcher keeps going assuming all is well). If the connection is not successful, and then asyncore.loop() is called, then select.select() will indicate that there is an error with the socket (can't connect) and the error will be logged. The trouble is that asyncore.loop then keeps going, and will log this error again. My not-that-fast system here gets about 10,000 logged messages per second with a single socket in the asyncore map. There are ways to avoid this: (1) if the socket is blocking when connect()ing (and then nonblocking afterwards) an error is raised if the connect fails. (2) Before calling asyncore.loop(), the caller can run through all the sockets, checking that they are ok. (3) handle_expt() can be overridden with a function that repairs or removes the socket from the map (etc) However, I'm not convinced that this is good behavior for asyncore to have, by default. On Windows, select.select() will only indicate an error when trying to connect (nonblocking) or if SO_OOBINLINE is disabled, but this may not be the case (i.e. errors can occur at other times) with other platforms, right? Unless the error is temporary, asyncore will by default start streaming (extremely fast) a lot of "warning: unhandled exception" (not very helpful an error message, either) messages. Even if the error only lasts a minute, that could easily result in 10,000 warnings being logged. Do any of the python developers agree that this is a flaw? I'm happy to work up a patch for whatever the desired solution is, if so. -- >Comment By: Josiah Carlson (josiahcarlson) Date: 2007-01-06 15:11 Message: Logged In: YES user_id=341410 Originator: NO Can I get any pointers as to a conversion from CVS to SVN version numbers, or does anyone remember which change is the issue? -- Comment By: Tim Peters (tim_one) Date: 2005-06-09 09:11 Message: Logged In: YES user_id=31435 My guess is rev 1.57. -- Comment By: A.M. Kuchling (akuchling) Date: 2005-06-09 08:41 Message: Logged In: YES user_id=11375 What change to asyncore caused the problem? -- Comment By: Tim Peters (tim_one) Date: 2005-06-02 19:02 Message: Logged In: YES user_id=31435 I agree the change in default behavior here was at least questionable, and spent more than a week of my own "dealing with consequences" of 2.4 asyncore changes in ZODB and Zope. Assigning to Andrew, since it looks like he made the change in question here. Andrew, why did this change? How can it be improved? I don't think Tony has mentioned it here, but when SpamBayes was first released with Python 2.4, it was a disaster because some users found their hard drives literally filled with gigabytes of mysterious "warning: unhandled exception" messages. -- Comment By: Tony Meyer (anadelonbrin) Date: 2005-06-02 18:38 Message: Logged In: YES user_id=552329 I am not at all unwilling (and this isn't a problem for me personally - the issue here is whether this is good for Python in general) to subclass. Deciding to subclass does *not* mean that you should have to replace all functions in the parent class. If you did, then there would be little point in subclassing at all. Sensible default behaviour should be provided as methods of classes. The current behaviour of the handle_expt() method is not sensible. It essentially forces the user to override that method, even if they have no interest in handling errors (e.g. and would normally just override handle_read and handle_write). This is *not* rare. You haven't seen any i
[ python-Bugs-953599 ] asyncore misses socket closes when poll is used
Bugs item #953599, was opened at 2004-05-13 14:47 Message generated for change (Comment added) made by josiahcarlson You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=953599&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: Python Library Group: None Status: Open Resolution: None Priority: 6 Private: No Submitted By: Shane Kerr (shane_kerr) Assigned to: Josiah Carlson (josiahcarlson) Summary: asyncore misses socket closes when poll is used Initial Comment: Problem: If the loop() function of asyncore is invoked with poll rather than select, the function readwrite() is used when I/O is available on a socket. However, this function does not check for hangup - provided by POLLHUP. If a socket is attempting to write, then POLLOUT never gets set, so the socket hangs. Because poll() is returning immediately, but the return value is never used, asyncore busy-loops, consuming all available CPU. Possible solutions: The easy solution is to check for POLLHUP in the readwrite() function: if flags & (select.POLLOUT | select.POLLHUP): obj.handle_write_event() This makes the poll work exactly like the select - the application raises a socket.error set to EPIPE. An alternate solution - possibly more graceful - is to invoke the handle_close() method of the object: if flags & select.POLLHUP: obj.handle_close() else: if flags & select.POLLIN: obj.handle_read_event() if flags & select.pollout: obj.handle_write_event() This is incompatible with the select model, but it means that the read and write logic is now the same for socket hangups - handle_close() is invoked. -- >Comment By: Josiah Carlson (josiahcarlson) Date: 2007-01-06 15:21 Message: Logged In: YES user_id=341410 Originator: NO The solution suggested by klimkin seems to have made it into revision 35513 as a fix to bug #887279. I'm not sure that this is necessarily the right solution to this bug or #887279, as a socket disconnect isn't necessarily an error condition, otherwise .handle_close_event() shouldn't exist for select-based loops, and it should always be an error. Suggest switching to the last if clause of readwrite() to... if flags & (select.POLLERR | select.POLLNVAL): obj.handle_expt_event() if flags & select.POLLHUP: obj.handle_close_event() -- Comment By: Alexey Klimkin (klimkin) Date: 2004-07-02 06:56 Message: Logged In: YES user_id=410460 Perhaps, it would be better to raise exception: def readwrite(obj, flags): try: if flags & (select.POLLIN | select.POLLPRI): obj.handle_read_event() if flags & select.POLLOUT: obj.handle_write_event() if flags & (select.POLLERR | select.POLLHUP | select.POLLNVAL): obj.handle_expt_event() except ExitNow: raise except: obj.handle_error() ... def handle_expt_event(self): err = self.socket.getsockopt(socket.SOL_SOCKET, socket.SO_ERROR) assert(err != 0) raise socket.error, (err, errorcode[err]) Since asyncore closes socket in handle_error, this solves the problem too. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=953599&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1063924 ] asyncore should handle ECONNRESET in send
Bugs item #1063924, was opened at 2004-11-10 08:27 Message generated for change (Comment added) made by josiahcarlson You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1063924&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: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Florent Guillaume (efge) Assigned to: Josiah Carlson (josiahcarlson) Summary: asyncore should handle ECONNRESET in send Initial Comment: asyncore.dispatcher.send doesn't handle ECONNRESET, whereas recv correctly does. When such an error occurs, Zope displays for instance: ERROR(200) ZServer uncaptured python exception, closing channel (socket.error:(104, 'Connection reset by peer') [/usr/local/lib/python2.3/asynchat.py|initiate_send|218] [/usr/local/zope/2.7.2/lib/python/ZServer/medusa/http_server.py|send|417] [/usr/local/lib/python2.3/asyncore.py|send|337]) zhttp_channel is just a subclass of http_channel. The exception is raised by asyncore itself when it receives the unhandled error. A proposed fix would be to do the same kind of handling than is done in recv, but I don't know enough about asyncore to know if it's correct -- >Comment By: Josiah Carlson (josiahcarlson) Date: 2007-01-06 21:49 Message: Logged In: YES user_id=341410 Originator: NO It would seem to me that a connection where sending raises ECONNRESET, ENOTCONN, or ESHUTDOWN, should be closed, as is the case in recv. However, generally send is usually called before recv, so if we close the connection in send, then recv won't get called. In basically all cases, we want recv() to be called so that we get data from the buffers if possible. Usually if there is data in the buffers, an exception won't be raised, so we wouldn't close the connection until the next pass. If we make a change at all, I would change send() to: def send(self, data): try: result = self.socket.send(data) return result except socket.error, why: if why[0] == EWOULDBLOCK: return 0 elif why[0] in [ECONNRESET, ENOTCONN, ESHUTDOWN]: return 0 else: raise I have not yet tested the behavior in Python 2.5 yet, as the test cases for Python 2.5 asyncore are basically nonexistent. If we added portions of the test cases provided in patch #909005, we could more easily test these kinds of things. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1063924&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-539444 ] asyncore file wrapper & os.error
Bugs item #539444, was opened at 2002-04-04 12:57 Message generated for change (Comment added) made by josiahcarlson You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=539444&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: Python Library Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Jeremy Hylton (jhylton) Assigned to: Josiah Carlson (josiahcarlson) Summary: asyncore file wrapper & os.error Initial Comment: The file wrapper makes a file descriptor look like an asycnore socket. When its recv() method is invoked, it calls os.read(). I use this in an application where os.read() occasionally raises os.error (11, 'Resource temporarily unavailable'). I think that asyncore should catch this error and treat it just like EWOULDBLOCK. But I'd like a second opinion. -- >Comment By: Josiah Carlson (josiahcarlson) Date: 2007-01-06 22:00 Message: Logged In: YES user_id=341410 Originator: NO I don't see an issue with treating EAGAIN as EWOULDBLOCK. In the cases where EAGAIN != EWOULDBLOCK (in terms of constant value), treating them the same would be the right thing. In the case where the values were the same, nothing would change. -- Comment By: Martin v. Löwis (loewis) Date: 2002-04-07 01:03 Message: Logged In: YES user_id=21627 I'm still uncertain what precisely was happening here. What system was this on? On many systems, EAGAIN is EWOULDBLOCK; if that is the case, adding EAGAIN to the places that currently handle EWOULDBLOCK won't change anything. -- Comment By: Jeremy Hylton (jhylton) Date: 2002-04-05 08:44 Message: Logged In: YES user_id=31392 It happens when the file is a pipe. For details, see the ZEO bug report at https://sourceforge.net/tracker/index.php? func=detail&aid=536416&group_id=15628&atid=115628 I've included the traceback from that bug report, too. error: uncaptured python exception, closing channel(exceptions.OSError:[Errno 11] Resource temporarily unavailable [/home/zope/opt/Python- 2.1.2/lib/python2.1/asyncore.py|poll|92] [/home/zope/opt/Python- 2.1.2/lib/python2.1/asyncore.py|handle_read_event|386] [/home/zope/opt/Python-2.1.2/lib/python2.1/site- packages/ZEO/trigger.py|handle_read|95] [/home/zope/opt/Python- 2.1.2/lib/python2.1/asyncore.py|recv|338] [/home/zope/opt/Python- 2.1.2/lib/python2.1/asyncore.py|recv|520]) Exception exceptions.OSError: (9, 'Bad file descriptor') in ignored -- Comment By: Martin v. Löwis (loewis) Date: 2002-04-05 01:00 Message: Logged In: YES user_id=21627 Can you report details of the file that returns EWOULDBLOCK? This is not supposed to happen in applications of the file_wrapper. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=539444&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-658749 ] asyncore connect() and winsock errors
Bugs item #658749, was opened at 2002-12-26 10:25 Message generated for change (Comment added) made by josiahcarlson You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=658749&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: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Guido van Rossum (gvanrossum) Assigned to: Josiah Carlson (josiahcarlson) Summary: asyncore connect() and winsock errors Initial Comment: asyncore's connect() method should interpret the winsock errors; these are different from Unix (and different between the Win98 family and the Win2k family). -- >Comment By: Josiah Carlson (josiahcarlson) Date: 2007-01-06 22:10 Message: Logged In: YES user_id=341410 Originator: NO klimkin: Please explain how either of the versions of patch #909005 fix the problem. From what I can tell, the only change you made was to move the accept() handling of errors to the handle_read() method. Guido: In terms of winsock errors, which are actually raised on connection error between win98, win2k, and/or XP, 2003, and Vista? -- Comment By: Alexey Klimkin (klimkin) Date: 2004-03-04 00:24 Message: Logged In: YES user_id=410460 Patch #909005 fixes the problem. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=658749&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-654766 ] asyncore.py and "handle_expt"
Bugs item #654766, was opened at 2002-12-16 10:42
Message generated for change (Comment added) made by josiahcarlson
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=654766&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: Python Library
>Group: Python 2.2
>Status: Pending
>Resolution: Out of Date
Priority: 5
Private: No
Submitted By: Jes�s Cea Avi�n (jcea)
Assigned to: Josiah Carlson (josiahcarlson)
Summary: asyncore.py and "handle_expt"
Initial Comment:
Python 2.2.2 here.
Asyncore.py doesn't invoke "handle_expt" ever
("handle_expt" is documented in docs). Managing OOB
data is imprescindible to handle "connection refused"
errors in Windows, for example.
--
>Comment By: Josiah Carlson (josiahcarlson)
Date: 2007-01-06 22:18
Message:
Logged In: YES
user_id=341410
Originator: NO
According to the most recent Python trunk, handle_expt() is called when an
error is found within a .select() or .poll() call.
Is this still an issue for you in Python 2.4 or Python 2.5?
Setting status as Pending, Out of Date as I believe this bug is fixed.
--
Comment By: Alexey Klimkin (klimkin)
Date: 2004-03-04 00:24
Message:
Logged In: YES
user_id=410460
Patch #909005 fixes the problem.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=654766&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-777588 ] asyncore is broken for windows if connection is refused
Bugs item #777588, was opened at 2003-07-25 07:43 Message generated for change (Comment added) made by josiahcarlson You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=777588&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: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Garth Bushell (garth42) Assigned to: Josiah Carlson (josiahcarlson) Summary: asyncore is broken for windows if connection is refused Initial Comment: asyncore.poll is broken on windows. If a connection is refused happens it will hang for ever and never raise an exception. The Select statment never checks the exfds. This is needed as this is where windows reports failed connections. The documentation in the microsoft platform SDK mentions this. http://msdn.microsoft.com/library/default.asp?url=/library/en-us/winsock/winsock/select_2.asp The suggested fix is shown below althought this is untested. The correct error number is recived from getsockopt(SOL_SOCKET,SO_ERROR) def poll(timeout=0.0, map=None): if map is None: map = socket_map if map: r = []; w = []; e = [] for fd, obj in map.items(): if obj.readable(): r.append(fd) if obj.writable(): w.append(fd) if sys.platform == 'win32': if not obj.connected: e.append(fd) if [] == r == w == e: time.sleep(timeout) else: try: r, w, e = select.select(r, w, e, timeout) except select.error, err: if err[0] != EINTR: raise else: return if sys.platform == 'win32': for fd in e: obj = map.get(fd) if obj is None: continue errno = fs.getsockopt(socket.SOL_SOCKET, socket.SO_ERROR) raise socket.error,(errno,socketerrorTab[error]) for fd in r: obj = map.get(fd) if obj is None: continue read(obj) for fd in w: obj = map.get(fd) if obj is None: continue write(obj) -- >Comment By: Josiah Carlson (josiahcarlson) Date: 2007-01-06 22:19 Message: Logged In: YES user_id=341410 Originator: NO I am looking into applying a variant of portions of #909005 to fix this bug. -- Comment By: Alexey Klimkin (klimkin) Date: 2004-03-04 00:23 Message: Logged In: YES user_id=410460 Patch #909005 fixes the problem. -- Comment By: John J Smith (johnjsmith) Date: 2003-07-29 05:49 Message: Logged In: YES user_id=830565 I was bitten by the same problem. My workaround (in a Tkinter application) is given below. Would it make sense to modify poll() to simply add the union of r and w to e, and call handle_error() for any fd in e? Workaround: try: self.connect(send_addr) except socket.error: self.handle_error() if sys.platform == 'win32': # Win98 select() doesn't seem to report errors for a # non-blocking connect(). self.__connected = 0 self.__frame.after(2000, self.__win_connect_poll) ... if sys.platform == 'win32': def __win_connect_poll (self): if self.__connected: return e = self.socket.getsockopt(socket.SOL_SOCKET, socket.SO_ERROR) if e in (0, errno.EINPROGRESS, errno.WSAEINPROGRESS): self.__frame.after(2000, self.__win_connect_poll) else: try: str = socket.errorTab[e] except KeyError: str = os.strerror(e) try: raise socket.error(e, str) except socket.error: self.handle_error() -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=777588&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
