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

Determining the failure of C API call is ambiguous #70963

Open
serhiy-storchaka opened this issue Apr 16, 2016 · 2 comments
Open

Determining the failure of C API call is ambiguous #70963

serhiy-storchaka opened this issue Apr 16, 2016 · 2 comments
Labels
interpreter-core (Objects, Python, Grammar, and Parser dirs)

Comments

@serhiy-storchaka
Copy link
Member

BPO 26776
Nosy @vstinner, @serhiy-storchaka
Files
  • check_error_occurred.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 = None
    created_at = <Date 2016-04-16.08:02:38.488>
    labels = ['interpreter-core']
    title = 'Determining the failure of C API call is ambiguous'
    updated_at = <Date 2016-04-16.09:27:24.259>
    user = 'https://github.com/serhiy-storchaka'

    bugs.python.org fields:

    activity = <Date 2016-04-16.09:27:24.259>
    actor = 'vstinner'
    assignee = 'none'
    closed = False
    closed_date = None
    closer = None
    components = ['Interpreter Core']
    creation = <Date 2016-04-16.08:02:38.488>
    creator = 'serhiy.storchaka'
    dependencies = []
    files = ['42478']
    hgrepos = []
    issue_num = 26776
    keywords = ['patch']
    message_count = 2.0
    messages = ['263540', '263544']
    nosy_count = 2.0
    nosy_names = ['vstinner', 'serhiy.storchaka']
    pr_nums = []
    priority = 'normal'
    resolution = None
    stage = None
    status = 'open'
    superseder = None
    type = None
    url = 'https://bugs.python.org/issue26776'
    versions = []

    @serhiy-storchaka
    Copy link
    Member Author

    C API functions returns a special value unambiguously signaling about a raised exception (NULL or -1). But in some cases this is ambiguous, because the special value is a legitimate value (e.g. -1 for PyLong_AsLong() or NULL for PyDict_GetItem()). Needed to use PyErr_Occurred() to distinguish between successful and failed call.

    The problem is that if PyLong_AsLong() is called when the exception is set, successful call returned -1 is interpreted as failed. Since it is happen in very rare case, this bug is usually unnoticed.

    Attached experimental patch makes some functions like PyLong_AsLong() always failing if called with an exception set. Some tests are failed with it applied: test_compile test_datetime test_io test_os test_symtable test_syntax test_xml_etree_c.

    @serhiy-storchaka serhiy-storchaka added the interpreter-core (Objects, Python, Grammar, and Parser dirs) label Apr 16, 2016
    @vstinner
    Copy link
    Member

    Ah yes. Some months (years?) ago, i started to add assertions to fail if
    some functions are called with an exception set.

    Checking if an exception is set at runtime adds a low overhead. Maybe it's
    better to fail with a fatal error (like an assertion error) in debug mode
    (and do nothing in release mode).

    But I'm not sure that developers of C extensions are all able to get a
    Python compiled in debug mode :-/ That's also why I added a check a
    runtime: raise a SystemError if a function with an exception set. I also
    added PYTHONMALLOC=debug to make some debug checks easily available on
    release builds.

    The bug also reminds me my PEP-490 to chain exceptions. It would be
    yet another option...

    So well, I don't know what is the best option.

    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

    2 participants