homepage

This issue tracker has been migrated to GitHub , and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author amaury.forgeotdarc
Recipients amaury.forgeotdarc, hanji, ned.deily
Date 2011年12月07日.13:29:56
SpamBayes Score 6.661338e-16
Marked as misclassified No
Message-id <1323264597.58.0.203570016568.issue13546@psf.upfronthosting.co.za>
In-reply-to
Content
Tested on Linux:
Python 2.7.2+ (2.7:16c4137a413c+, Dec 4 2011, 22:56:38) 
[GCC 4.4.3] on linux2
>>> import sys
>>> sys.setrecursionlimit((1<<31)-1)
>>> import xx
Exception RuntimeError: 'maximum recursion depth exceeded in __subclasscheck__' in <type 'exceptions.ImportError'> ignored
Exception RuntimeError: 'maximum recursion depth exceeded in __subclasscheck__' in <type 'exceptions.ImportError'> ignored
Traceback (most recent call last):
This comes from PyErr_GivenExceptionMatches() which tries to "Temporarily bump the recursion limit", and calls Py_SetRecursionLimit(reclimit + 5); without any consideration for 32bit int overflow... and PyErr_WriteUnraisable() is called to display the error.
IDLE crashes (with a real stack overflow) because sys.stderr is a special RPCProxy object whose methods are found through a __getattr__. But __getattr__ is called when __getattribute__ raises AttributeError, right? To implement this, PyErr_GivenExceptionMatches() is called again, fails again, call PyErr_WriteUnraisable()... recursively.
The fix should be easy: do not bump the recursion limit when it's already too high.
History
Date User Action Args
2011年12月07日 13:29:57amaury.forgeotdarcsetrecipients: + amaury.forgeotdarc, ned.deily, hanji
2011年12月07日 13:29:57amaury.forgeotdarcsetmessageid: <1323264597.58.0.203570016568.issue13546@psf.upfronthosting.co.za>
2011年12月07日 13:29:57amaury.forgeotdarclinkissue13546 messages
2011年12月07日 13:29:56amaury.forgeotdarccreate

AltStyle によって変換されたページ (->オリジナル) /