Skip to content

Better error handling in PyImport_Cleanup() #77511

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

Closed
serhiy-storchaka opened this issue Apr 22, 2018 · 11 comments
Closed

Better error handling in PyImport_Cleanup() #77511

serhiy-storchaka opened this issue Apr 22, 2018 · 11 comments
Labels
3.7 (EOL) end of life 3.8 (EOL) end of life interpreter-core (Objects, Python, Grammar, and Parser dirs) type-bug An unexpected behavior, bug, or error

Comments

@serhiy-storchaka
Copy link
Member

BPO 33330
Nosy @brettcannon, @ncoghlan, @pitrou, @vstinner, @ericsnowcurrently, @serhiy-storchaka, @miss-islington
PRs
  • bpo-33330: Improve error handling in PyImport_Cleanup(). #6564
  • [3.7] bpo-33330: Improve error handling in PyImport_Cleanup(). (GH-6564) #6601
  • [3.6] bpo-33330: Improve error handling in PyImport_Cleanup(). (GH-6564). #6604
  • [2.7] bpo-33330: Improve error handling in PyImport_Cleanup(). (GH-6564). #6605
  • bpo-33330: Write exceptions occurred in PyImport_Cleanup() to stderr. #6606
  • bpo-33330: PyImport_Cleanup check for exc leaks #7068
  • 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 = None
    created_at = <Date 2018-04-22.08:56:30.611>
    labels = ['interpreter-core', '3.8', 'type-bug', '3.7']
    title = 'Better error handling in PyImport_Cleanup()'
    updated_at = <Date 2018-05-23.10:36:34.627>
    user = 'https://github.com/serhiy-storchaka'

    bugs.python.org fields:

    activity = <Date 2018-05-23.10:36:34.627>
    actor = 'serhiy.storchaka'
    assignee = 'none'
    closed = False
    closed_date = None
    closer = None
    components = ['Interpreter Core']
    creation = <Date 2018-04-22.08:56:30.611>
    creator = 'serhiy.storchaka'
    dependencies = []
    files = []
    hgrepos = []
    issue_num = 33330
    keywords = ['patch']
    message_count = 9.0
    messages = ['315592', '315751', '315756', '315757', '315766', '315767', '315915', '317367', '317381']
    nosy_count = 7.0
    nosy_names = ['brett.cannon', 'ncoghlan', 'pitrou', 'vstinner', 'eric.snow', 'serhiy.storchaka', 'miss-islington']
    pr_nums = ['6564', '6601', '6604', '6605', '6606', '7068']
    priority = 'normal'
    resolution = None
    stage = 'resolved'
    status = 'open'
    superseder = None
    type = 'behavior'
    url = 'https://bugs.python.org/issue33330'
    versions = ['Python 3.6', 'Python 3.7', 'Python 3.8']

    @serhiy-storchaka
    Copy link
    Member Author

    The proposed PR adds missed checks for errors and PyErr_Clear() calls in PyImport_Cleanup().

    It may be worth to use PyErr_WriteUnraisable() in place of PyErr_Clear() (newly added and existing) in most cases. But this can add an unexpected noise, and I don't wont to do this at this stage of 3.7. It could be done in 3.8 though, and backported to 3.7 later.

    I'm not sure that PyImport_Cleanup() works properly if sys.modules is not a dict. At this stage a custom mapping will likely be broken when most of modules are destroyed.

    @serhiy-storchaka serhiy-storchaka added 3.7 (EOL) end of life 3.8 (EOL) end of life interpreter-core (Objects, Python, Grammar, and Parser dirs) type-bug An unexpected behavior, bug, or error labels Apr 22, 2018
    @serhiy-storchaka
    Copy link
    Member Author

    New changeset e9d9494 by Serhiy Storchaka in branch 'master':
    bpo-33330: Improve error handling in PyImport_Cleanup(). (GH-6564)
    e9d9494

    @miss-islington
    Copy link
    Contributor

    New changeset 291c9d4 by Miss Islington (bot) in branch '3.7':
    bpo-33330: Improve error handling in PyImport_Cleanup(). (GH-6564)
    291c9d4

    @serhiy-storchaka
    Copy link
    Member Author

    PR 6606 replaces PyErr_Clear() with PyErr_WriteUnraisable(). This may add an unexpected noise at shutdown' but on other hand, this may be a helpful information in the case if something wrong happen. It doesn't produce additional output when run all tests, this means that that all is successful. I wonder in which circumstance that output will be occurred.

    @serhiy-storchaka
    Copy link
    Member Author

    New changeset b16681f by Serhiy Storchaka in branch '3.6':
    [3.6] bpo-33330: Improve error handling in PyImport_Cleanup(). (GH-6564). (GH-6604)
    b16681f

    @serhiy-storchaka
    Copy link
    Member Author

    New changeset 55299ff by Serhiy Storchaka in branch '2.7':
    [2.7] bpo-33330: Improve error handling in PyImport_Cleanup(). (GH-6564). (GH-6605)
    55299ff

    @serhiy-storchaka
    Copy link
    Member Author

    New changeset c1a6832 by Serhiy Storchaka in branch 'master':
    bpo-33330: Write exceptions occurred in PyImport_Cleanup() to stderr. (GH-6606)
    c1a6832

    @vstinner
    Copy link
    Member

    I reopen the issue because I created the PR 7068 to propose further checks (in debug mode).

    @vstinner vstinner reopened this May 23, 2018
    @serhiy-storchaka
    Copy link
    Member Author

    See also bpo-33379 about the bug in subinterpreters exposed when add yet one PyErr_WriteUnraisable() in PyImport_Cleanup() (it was not added because of this).

    @ezio-melotti ezio-melotti transferred this issue from another repository Apr 10, 2022
    @iritkatriel
    Copy link
    Member

    Is there anything left to do here?

    @vstinner
    Copy link
    Member

    I gave up on my further enhancements #7068 (comment), so I just close the issue.

    Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
    Labels
    3.7 (EOL) end of life 3.8 (EOL) end of life interpreter-core (Objects, Python, Grammar, and Parser dirs) type-bug An unexpected behavior, bug, or error
    Projects
    None yet
    Development

    No branches or pull requests

    4 participants