Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Py_SetFatalErrorAbortFunc: Allow embedding program to handle fatal errors #74745

Closed
thp mannequin opened this issue Jun 3, 2017 · 4 comments
Closed

Py_SetFatalErrorAbortFunc: Allow embedding program to handle fatal errors #74745

thp mannequin opened this issue Jun 3, 2017 · 4 comments
Labels
interpreter-core (Objects, Python, Grammar, and Parser dirs)

Comments

@thp
Copy link
Mannequin

thp mannequin commented Jun 3, 2017

BPO 30560
Nosy @vstinner, @thp
Files
  • Py_SetFatalErrorAbortFunc.patch
  • Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.

    Show more details

    GitHub fields:

    assignee = None
    closed_at = <Date 2019-05-27.15:12:59.534>
    created_at = <Date 2017-06-03.19:15:43.845>
    labels = ['interpreter-core']
    title = 'Py_SetFatalErrorAbortFunc: Allow embedding program to handle fatal errors'
    updated_at = <Date 2019-05-27.15:14:33.112>
    user = 'https://github.com/thp'

    bugs.python.org fields:

    activity = <Date 2019-05-27.15:14:33.112>
    actor = 'vstinner'
    assignee = 'none'
    closed = True
    closed_date = <Date 2019-05-27.15:12:59.534>
    closer = 'vstinner'
    components = ['Interpreter Core']
    creation = <Date 2017-06-03.19:15:43.845>
    creator = 'thomas.perl'
    dependencies = []
    files = ['46921']
    hgrepos = []
    issue_num = 30560
    keywords = ['patch']
    message_count = 4.0
    messages = ['295098', '295099', '343640', '343641']
    nosy_count = 2.0
    nosy_names = ['vstinner', 'thomas.perl']
    pr_nums = []
    priority = 'normal'
    resolution = 'fixed'
    stage = 'resolved'
    status = 'closed'
    superseder = None
    type = None
    url = 'https://bugs.python.org/issue30560'
    versions = ['Python 3.6']

    @thp
    Copy link
    Mannequin Author

    thp mannequin commented Jun 3, 2017

    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):

    gpodder/gpodder#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).

    @thp thp mannequin added the interpreter-core (Objects, Python, Grammar, and Parser dirs) label Jun 3, 2017
    @thp
    Copy link
    Mannequin Author

    thp mannequin commented Jun 3, 2017

    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();
    + }

    @vstinner
    Copy link
    Member

    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.

    @vstinner
    Copy link
    Member

    Note: if I misunderstood the issue, please open it ;-)

    @ezio-melotti ezio-melotti transferred this issue from another repository Apr 10, 2022
    Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
    Labels
    interpreter-core (Objects, Python, Grammar, and Parser dirs)
    Projects
    None yet
    Development

    No branches or pull requests

    1 participant