Message148966
| 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:57 | amaury.forgeotdarc | set | recipients:
+ amaury.forgeotdarc, ned.deily, hanji |
| 2011年12月07日 13:29:57 | amaury.forgeotdarc | set | messageid: <1323264597.58.0.203570016568.issue13546@psf.upfronthosting.co.za> |
| 2011年12月07日 13:29:57 | amaury.forgeotdarc | link | issue13546 messages |
| 2011年12月07日 13:29:56 | amaury.forgeotdarc | create |
|