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 vstinner
Recipients Tim.Graham, berker.peksag, pitrou, python-dev, serhiy.storchaka, vstinner
Date 2015-03-30.08:38:50
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <CAMpsgwasg7owAg1gaqM3Vf5gEXAgsO0CZJ+Mr7R55hxFj3HUkg@mail.gmail.com>
In-reply-to <1427694202.73.0.71537342366.issue23571@psf.upfronthosting.co.za>
Content
Serhiy Storchaka added the comment:
> The second (exception == NULL) check in _Py_PrintFatalError() looks suspicious. When it is possible? And if it is possible, can it cause leaks?

Sorry, I have no idea. I didn't write this code myself. It comes from
PyErr_PrintEx():

    PyErr_Fetch(&exception, &v, &tb);
    if (exception == NULL)
        return;
    PyErr_NormalizeException(&exception, &v, &tb);
    if (tb == NULL) {
        tb = Py_None;
        Py_INCREF(tb);
    }
    PyException_SetTraceback(v, tb);
    if (exception == NULL)
        return;

I read again PyErr_NormalizeException(). I'm not sure that the case
can occur in practice. Maybe it can be replaced with an assertion?
Since Py_FatalError() is called in catastrophic cases, I chose to not
try to drop safety checks :-) You can modify PyErr_PrintEx() or even
_Py_PrintFatalError() if you feel more brave than me :-D
History
Date User Action Args
2015-03-30 08:38:51vstinnersetrecipients: + vstinner, pitrou, python-dev, berker.peksag, serhiy.storchaka, Tim.Graham
2015-03-30 08:38:51vstinnerlinkissue23571 messages
2015-03-30 08:38:50vstinnercreate