Changes by Aleksi Torhamo :
--
keywords: +patch
Added file: http://bugs.python.org/file37660/python_codec_crash_fix.patch
___
Python tracker
<http://bugs.python.org/issue23
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 is in
Aleksi Torhamo 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 _abcoll.dict_proxy
I'll
Aleksi Torhamo 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 GetSetDescriptorType EllipsisType FrameType
New submission from Aleksi Torhamo :
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: slice froze
Aleksi Torhamo 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 it, when it
Aleksi Torhamo 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 ab
Aleksi Torhamo 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. I
Aleksi Torhamo 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
anyth
Aleksi Torhamo 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 with it
Aleksi Torhamo 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-dev2/browse_thread/t
Aleksi Torhamo 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, and that is - i think - co
12 matches
Mail list logo
