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 xdegaye
Recipients brett.cannon, pitrou, serhiy.storchaka, vstinner, xdegaye
Date 2017-06-18.14:49:42
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1497797382.86.0.706281512539.issue30697@psf.upfronthosting.co.za>
In-reply-to
Content
Problem b) is IMO a clear demonstration that using tstate->recursion_depth and the PyExc_RecursionErrorInst singleton is not the correct way to control the recursive calls to PyErr_NormalizeException() since the problem here is memory exhaustion, not recursion. One could instead abort with a Fatal Error message printing the type of the last exception, when the depth of the recursivity of PyErr_NormalizeException() exceeds let's say 128 (knowing that anyway the stack is protected in the functions that attempt to instantiate those exceptions). The normalization of an exception that fails with an exception whose normalization fails with an ... and this, 128 times in a row, surely this can be considered as a fatal error, no ?

PR 2035 eliminates the tail recursive call in PyErr_NormalizeException() and transforms it into a loop. This loop obviously does not involve the stack anymore. This is another argument that shows  that tstate->recursion_depth and the PyExc_RecursionErrorInst singleton which are related to the stack should not be used to control the recursivity of PyErr_NormalizeException() or the iterations of this loop.
History
Date User Action Args
2017-06-18 14:49:42xdegayesetrecipients: + xdegaye, brett.cannon, pitrou, vstinner, serhiy.storchaka
2017-06-18 14:49:42xdegayesetmessageid: <1497797382.86.0.706281512539.issue30697@psf.upfronthosting.co.za>
2017-06-18 14:49:42xdegayelinkissue30697 messages
2017-06-18 14:49:42xdegayecreate