[issue6589] smtpd.SMTPServer can cause asyncore.loop to enter infinite event loop
Casey McGinty added the comment: This is how it gets in an "invalid state". Not sure why you can't look at the code and see the mistake. "There is no code in the SMTPServere.__init__ method that catches the exception raised, caused by the failed bind attempt. After the exception is caught, the first thread continues to run, but asyncore is in an invalid state because it still has the registration of the second SMTPServer instance that never completed." As far as running in a thread. I have a program that needs must start and stop the SMTPServer dynamically. I did this by putting SMTPServer in a thread. Maybe there is another way to do it, but if you are not going to support this, then it should be documented. -- ___ Python tracker <http://bugs.python.org/issue6589> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6589] smtpd.SMTPServer can cause asyncore.loop to enter infinite event loop
Casey McGinty added the comment: I attached a simple script that reproduces the report issue. I hope it helps. -- Added file: http://bugs.python.org/file17807/smtp_test.py ___ Python tracker <http://bugs.python.org/issue6589> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3518] multiprocessing: BaseManager.from_address documented but doesn't exist
Casey McGinty added the comment: I would like to open this ticket back up. Python 2.6.2 docs still reference unimplemented 'from_address' method. http://docs.python.org/library/multiprocessing.html#multiprocessing.managers.BaseManager.from_address BaseManager.__reduce__ method also calls unimplemented 'from_address' method. This looks like a bug since there is no docs or comments that indicate it is as an abstract method. -- nosy: +casey.mcgi...@gmail.com ___ Python tracker <http://bugs.python.org/issue3518> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5862] multiprocessing 'using a remote manager' example errors and possible 'from_address' code leftover
Changes by Casey McGinty : -- nosy: +cmcginty ___ Python tracker <http://bugs.python.org/issue5862> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6589] smtpd.SMTPServer can cause asyncore.loop to enter infinite event loop
New submission from Casey McGinty : When subclass of smtpd.SMTPServer, it is possible the get asyncore.loop to enter an infinite loop where the following output is shown: . warning: unhandled write event warning: unhandled read event warning: unhandled write event warning: unhandled read event warning: unhandled write event warning: unhandled read event warning: unhandled write event warning: unhandled read event warning: unhandled write event warning: unhandled read event warning: unhandled write event warning: unhandled read event To reproduce: 1) Init SMTPServer class instance inside of Thread class and call asyncore.loop() 2) Init second SMTPServer class instance from a second Thread class, binding to the same address and port. The SMTPServer instance will raise an exception that socket cannot bind to the port in use. The socket exception must be caught at some level, and the program execution allowed to continue. 3) First SMTPServer thread will enter infinite event loop. Analysis: When the exception is raised in the second SMTPServer instance, the new instance has already registered itself with the asyncore library (ex: 'asyncore.dispatcher.__init__(self)'). There is no code in the SMTPServere.__init__ method that catches the exception raised, caused by the failed bind attempt. After the exception is caught, the first thread continues to run, but asyncore is in an invalid state because it still has the registration of the second SMTPServer instance that never completed. Workaround and Proposed Fix: A viable workaround seems to be catching the raised exception in __init__ method of the SMTPServer subclass, and call self.close() before re-raising the exception: class MySmtpServer( smtpd.SMTPServer, object ): def __init__( self, **kwargs ): try: super( _SmtpSink, self).__init__(**kwargs) except Exception as e: self.close() # cleanup asyncore after failure raise For a long term fix, I would recommend performing the asyncore.dispatcher.close() method call in the SMTPServer.__init__() method. -- components: Library (Lib) messages: 91002 nosy: cmcginty severity: normal status: open title: smtpd.SMTPServer can cause asyncore.loop to enter infinite event loop versions: Python 2.6 ___ Python tracker <http://bugs.python.org/issue6589> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6605] smtplib.SMTP.sendmail() rejected after quit(), connect() sequence, no HELO
New submission from Casey McGinty : The smtplib.SMTP.quit() method does not reset the 'helo_resp' and 'ehlo_resp' instance attributes. During the next smtplib.SMTP.sendmail(), the HELO/EHLO commands are not sent, and may cause the remote SMTP service to reject the message, due to improper protocol handshaking. To fix, self.helo_resp and self.ehlo_resp should be set to 'None' in the smtplib.SMTP.quit() method. -- components: Library (Lib) messages: 91107 nosy: cmcginty severity: normal status: open title: smtplib.SMTP.sendmail() rejected after quit(),connect() sequence, no HELO versions: Python 2.6 ___ Python tracker <http://bugs.python.org/issue6605> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6605] smtplib.SMTP.sendmail() rejected after quit(), connect() sequence, no HELO
Casey McGinty added the comment: Sorry, duplicate of #4142 -- type: -> behavior ___ Python tracker <http://bugs.python.org/issue6605> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4544] textwrap: __all__ atribute missing 'dedent' functino
New submission from Casey McGinty <[EMAIL PROTECTED]>: >From textwrap.py: 46863 2006-06-11 19:42:51Z tim.peters The __all__ define in this module is missing the helper function 'dedent'. This causes pydoc to not the list the function correctly. Secondly, it also prevents 'dedent' from being imported when using 'from textwrap import *' (Yes, yes, I know this should never be done. Hence why it is probably never noticed by anyone.) -- components: Extension Modules messages: 76986 nosy: wolfdown severity: normal status: open title: textwrap: __all__ atribute missing 'dedent' functino type: feature request versions: Python 2.5 ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue4544> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4544] textwrap: __all__ atribute missing 'dedent' function
Changes by Casey McGinty <[EMAIL PROTECTED]>: -- title: textwrap: __all__ atribute missing 'dedent' functino -> textwrap: __all__ atribute missing 'dedent' function ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue4544> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
