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 ZackerySpytz, graingert, matrixise, serhiy.storchaka, vstinner
Date 2019-05-09.22:17:55
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
Ok, let me come back to the initial issue:

Thomas Grainger:
> Currently it's quite easy for these errors to go unnoticed. I'd like a way to easily detect these in CI. nedbat suggested piping the process output to another tool, and looking for 'Exception ignored in:' but this seems a little diff

When PyErr_WriteUnraisable() is called before Python finalization, my PR 13187 allows to handle these exceptions: log them in a dedicated file, abort the process, maybe even open a network connection, etc. The hook allows to implement your chosen behavior.

The problem is more during Python finalization: see attached example and my previous comment. If PyErr_WriteUnraisable() is called after sys.stderr is closed or closed to None, the function does nothing: the exception is not logged.

The question now becomes: do *all* calls to PyErr_WriteUnraisable() must abort the process? What is the point? Only a very low level debugger like gdb can be used to see the exception.

@Thomas Grainger: Do you want to have to use gdb to trace such very level exception?

IMHO sadly when PyErr_WriteUnraisable() is called way too late, we should simply ignore such exceptions. And so my PR 13187 is good enough to cover most cases.

If someone cares about exceptions raised very late during Python finalization, Python finalization should be enhanced. But this code is very fragile and is not deterministic. It is a work in progress for years to enhance it.
Date User Action Args
2019-05-09 22:17:55vstinnersetrecipients: + vstinner, serhiy.storchaka, graingert, matrixise, ZackerySpytz
2019-05-09 22:17:55vstinnersetmessageid: <>
2019-05-09 22:17:55vstinnerlinkissue36829 messages
2019-05-09 22:17:55vstinnercreate