classification
Title: Py_SetFatalErrorAbortFunc: Allow embedding program to handle fatal errors
Type: Stage: resolved
Components: Interpreter Core Versions: Python 3.6
process
Status: closed Resolution: fixed
Dependencies: Superseder:
Assigned To: Nosy List: thomas.perl, vstinner
Priority: normal Keywords: patch

Created on 2017-06-03 19:15 by thomas.perl, last changed 2019-05-27 15:14 by vstinner. This issue is now closed.

Files
File name Uploaded Description Edit
Py_SetFatalErrorAbortFunc.patch thomas.perl, 2017-06-03 19:15 review
Messages (4)
msg295098 - (view) Author: Thomas Perl (thomas.perl) * Date: 2017-06-03 19:15
In our application that embeds a Python interpreter, we had the issue that certain system configurations (namely, a lone "libpython27.dll" without any standard library) caused silent failures (note that this is using Python 2.7, but Python 3.x would be similarly affected, as the Py_FatalError() handling is still the same):

https://github.com/gpodder/gpodder/issues/286

There exists a Stack Overflow thread about this:

https://stackoverflow.com/questions/7688374/how-to-i-catch-and-handle-a-fatal-error-when-py-initialize-fails

The workaround described therein is:

"I solved this by creating a separate executable that attempts to initialize python. My primary process will launch it and check the exit code and only call PyInitialize if the child process was successful. So, python is initialized twice, but it is better than an apparent crash to the user."

So, what if instead we allow the embedding program to set a function pointer to a function that will get called instead of abort()? We have to make clear in the docs that after this function is called, the Python interpreter cannot be used, and the application should probably exit, but at least it would allow applications to capture the error message and show it to the user (e.g. using a MessageBox() on Windows) before exiting -- see attached patch.

Any alternative solutions would be fine as well that don't require us to create a new process and "try to" Py_Initialize() there, especially since Py_FatalError() might potentially be called in other places and in all those cases, a user-visible dialog would be better than an apparent "crash" (application exits).
msg295099 - (view) Author: Thomas Perl (thomas.perl) * Date: 2017-06-03 19:21
Quick fix for the patch: Of course, the line with abort() needs to be removed before this block:

+    if (_fatal_error_abort_func != NULL) {
+        _fatal_error_abort_func(msg);
+    } else {
+        abort();
+    }
msg343640 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2019-05-27 15:12
The issue has been fixed in bpo-36763 with the implementation of the PEP 587. A new API now allow to handle Python initialization error with a new PyStatus structure.

By the way, bpo-1195571 was a similar issue.
msg343641 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2019-05-27 15:14
Note: if I misunderstood the issue, please open it ;-)
History
Date User Action Args
2019-05-27 15:14:33vstinnersetmessages: + msg343641
2019-05-27 15:12:59vstinnersetstatus: open -> closed

nosy: + vstinner
messages: + msg343640

resolution: fixed
stage: resolved
2017-06-03 19:21:52thomas.perlsetmessages: + msg295099
2017-06-03 19:15:43thomas.perlcreate