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

Fatal error in dbm.gdbm #66234

Open
serhiy-storchaka opened this issue Jul 22, 2014 · 7 comments
Open

Fatal error in dbm.gdbm #66234

serhiy-storchaka opened this issue Jul 22, 2014 · 7 comments
Labels
extension-modules C modules in the Modules dir type-crash A hard crash of the interpreter, possibly with a core dump

Comments

@serhiy-storchaka
Copy link
Member

BPO 22035
Nosy @vstinner, @serhiy-storchaka
Files
  • dbm_gdbm_fatal_error.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 2014-07-22.10:20:40.004>
    labels = ['extension-modules', 'type-crash']
    title = 'Fatal error in dbm.gdbm'
    updated_at = <Date 2019-03-15.22:15:58.161>
    user = 'https://github.com/serhiy-storchaka'

    bugs.python.org fields:

    activity = <Date 2019-03-15.22:15:58.161>
    actor = 'BreamoreBoy'
    assignee = 'none'
    closed = False
    closed_date = None
    closer = None
    components = ['Extension Modules']
    creation = <Date 2014-07-22.10:20:40.004>
    creator = 'serhiy.storchaka'
    dependencies = []
    files = ['36031']
    hgrepos = []
    issue_num = 22035
    keywords = ['patch', 'needs review']
    message_count = 7.0
    messages = ['223658', '236005', '236006', '239688', '239689', '239773', '239778']
    nosy_count = 2.0
    nosy_names = ['vstinner', 'serhiy.storchaka']
    pr_nums = []
    priority = 'normal'
    resolution = None
    stage = 'patch review'
    status = 'open'
    superseder = None
    type = 'crash'
    url = 'https://bugs.python.org/issue22035'
    versions = ['Python 2.7', 'Python 3.4', 'Python 3.5']

    @serhiy-storchaka
    Copy link
    Member Author

    It is possible to crash Python by breaking opened gdbm database.

    >>> import _gdbm as dbm
    >>> db = dbm.open('x.db', 'n')
    >>> open('x.db', 'wb').close()
    >>> db[b'a'] = b'b'
    gdbm fatal: read error

    Proposed patch tries to convert fatal gdbm into regular exception or in Python fatal error (which at least produces traceback).

    >>> import _gdbm as dbm
    >>> db = dbm.open('x.db', 'n')
    >>> open('x.db', 'wb').close()
    >>> db[b'a'] = b'b'
    Traceback (most recent call last):
      File "<stdin>", line 1, in <module>
    _gdbm.error: gdbm fatal: read error

    @serhiy-storchaka serhiy-storchaka added extension-modules C modules in the Modules dir type-crash A hard crash of the interpreter, possibly with a core dump labels Jul 22, 2014
    @BreamoreBoy
    Copy link
    Mannequin

    BreamoreBoy mannequin commented Feb 14, 2015

    Would somebody please review Serhiy's patch.

    @serhiy-storchaka
    Copy link
    Member Author

    Oh, Mark, please stop shaking up bug tracker.

    @vstinner
    Copy link
    Member

    I would prefer to avoid setgmp/longjmp, it's kind of a hack. It's maybe more a design issue in the gdbm library to report errors.

    I proposed a generic signal handler using setjmp/longjmp to convert SIGSEGV to regular Python exceptions, but it was rejected: issue bpo-3999.

    @vstinner
    Copy link
    Member

    Oh, Mark, please stop shaking up bug tracker.

    I agree: please stop posting useless messages, and review patches instead.

    @serhiy-storchaka
    Copy link
    Member Author

    The patch for bpo-3999 was rejected because Python internal state may be corrupted when the SIGSEGV signal is raised. This is not the case of this issue. gdbm fatal function is called when Python is in consistent state. So we free to use any Python C-API. But internal state of concrete GDBM_FILE may be corrupted, so we shouldn't use it after handling fatal error. This cause a leak, but I think that a leak with an exception is better than just a crash.

    May be different type of exception should be raised. May be we need FatalError that inherits from BaseException.

    Other external libraries used by the stdlib also can crash, and perhaps crashes can be converted to exceptions. This issue is only first in the series.

    @vstinner
    Copy link
    Member

    vstinner commented Apr 1, 2015

    2015-04-01 10:39 GMT+02:00 Serhiy Storchaka <report@bugs.python.org>:

    Other external libraries used by the stdlib also can crash, and perhaps crashes can be converted to exceptions. This issue is only first in the series.

    I don't think that it's a good practice to try to workaround bugs. IMO
    it's better to modify libraries directly to allow users of the library
    to handle correctly errors.

    @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
    extension-modules C modules in the Modules dir type-crash A hard crash of the interpreter, possibly with a core dump
    Projects
    None yet
    Development

    No branches or pull requests

    2 participants