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 brett.cannon
Recipients ajaksu2, amaury.forgeotdarc, barry, benjamin.peterson, brett.cannon, nnorwitz, theller
Date 2008-08-14.02:36:42
SpamBayes Score 9.499375e-06
Marked as misclassified No
Message-id <bbaeab100808131936y58107e9em4299a3d4f9fbe3d6@mail.gmail.com>
In-reply-to <1218656975.86.0.667836320722.issue2548@psf.upfronthosting.co.za>
Content
On Wed, Aug 13, 2008 at 12:49 PM, Daniel Diniz <report@bugs.python.org> wrote:
>
> Daniel Diniz <ajaksu@gmail.com> added the comment:
>
> FWIW, rev58032 introduced this:
>    tstate = PyThreadState_GET();
>    if (++tstate->recursion_depth > Py_GetRecursionLimit()) {
>        --tstate->recursion_depth;
>        PyErr_SetObject(PyExc_RuntimeError, PyExc_RecursionErrorInst);
>        return;
>    }
> above this line:
>    PyErr_NormalizeException(exc, val, tb);
>
> Contrary to (what I understand from) Amaury's analysis, ISTM that the
> call to PyErr_SetObject is the problem, as after the recursion limit is
> hit PyErr_NormalizeException isn't called again.
>
> Commenting off the PyErr_SetObject line suppresses the "undetected
> errors" and passes the unittests (including the infinite recursion
> crashers removed in that rev). I have no idea about the problems it may
> cause, though.
>

If I remember correctly, that is on purpose as normalizing the
exception could lead to the stack being blown again. But this totally
off of memory, so I could be wrong.
History
Date User Action Args
2008-08-14 02:36:44brett.cannonsetrecipients: + brett.cannon, barry, nnorwitz, theller, amaury.forgeotdarc, ajaksu2, benjamin.peterson
2008-08-14 02:36:43brett.cannonlinkissue2548 messages
2008-08-14 02:36:42brett.cannoncreate