Aleksi Torhamo alexerion+pythonb...@gmail.com added the comment:
Please correct me, if i'm wrong, but this seems to be a real bug, caused
by people thinking that handle_expt is something like handle_error.
As Tony stated, the docs say that handle_expt is called when out-of-band
data arrives
Aleksi Torhamo alexerion+pythonb...@gmail.com added the comment:
Sorry for the noise.
I just registered, and started going through the open issues for
asyncore in order. I'll read them all through before commenting on the
next one..
I also bumped to this:
http://groups.google.com/group/python
Aleksi Torhamo alexerion+pythonb...@gmail.com added the comment:
The _exception() - close() change seems to be wrong. The third set of
select() is supposed to represent oob data, so the previous use in the
select-based loop should have been correct?
Other than that, i can't see anything wrong
Aleksi Torhamo alexerion+pythonb...@gmail.com added the comment:
Ah, you're right. I hadn't thought about the exceptional condition being
used to signal anything besides OOB.
Looks really good to me.
s/close/_exception/ in the select-based poll(), and i don't have
anything more to add
Aleksi Torhamo alexerion+pythonb...@gmail.com added the comment:
not the handle_close_event() replacements, stick with handle_close().
I'm guessing this has to do with breaking the abstraction?
I can't think of a situation where handle_close() is called, but close()
should not be called
Aleksi Torhamo alexerion+pythonb...@gmail.com added the comment:
I just remembered that level 1 function handle_connect_event() is also
called from level 2, so i actually can't see why the close helper
could not be called handle_close_event(). Is there some other reason
besides breaking
Aleksi Torhamo alexerion+pythonb...@gmail.com added the comment:
It's already done automatically if you don't override handle_close.
Sorry, i meant the case where you need to override it. If we always need
to call close() from handle_close(), it feels redundant having to
remember to add
New submission from Aleksi Torhamo alexerion+pythonb...@gmail.com:
object.__getattribute__(super, '__bases__') crashes the interpreter.
It seems to happen at Objects/typeobject.c in type_get_bases(), when
tp_bases is NULL.
Crashing types in __builtins__ per version would seem to be:
python2.4
Aleksi Torhamo alexerion+pythonb...@gmail.com added the comment:
Just verified that r71722 fixes all the builtins, however i just noticed
that some types under module types cause segfaults too.
Under python2.7 those are: CodeType BuiltinMethodType DictProxyType
GeneratorType
Aleksi Torhamo alexerion+pythonb...@gmail.com added the comment:
Stumbled upon a few more.
python2.4/2.5: socket.SSLType re._pattern_type weakref.ProxyType
weakref.CallableProxyType
python2.6/2.7: weakref.ProxyType weakref.CallableProxyType
python3.0: weakref.ProxyType weakref.CallableProxyType
Changes by Aleksi Torhamo alexerion+pythonb...@gmail.com:
--
keywords: +patch
Added file: http://bugs.python.org/file37660/python_codec_crash_fix.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue23215
New submission from Aleksi Torhamo:
Using a multibyte codec and a custom error handler that ignores errors to
encode a string that contains characters not representable in said encoding
causes exponential growth of the output buffer, raising MemoryError.
The problem
12 matches
Mail list logo
