Skip to content

Fatal error in dbm.gdbm #66234

Closed as not planned
Closed as not planned
Fatal error in dbm.gdbm#66234
Assignees
serhiy-storchaka
Labels
3.13only security fixes3.14bugs and security fixes3.15bugs and security fixesextension-modulesC modules in the Modules dirstdlibStandard Library Python modules in the Lib/ directorytriagedThe issue has been accepted as valid by a triager.type-crashA hard crash of the interpreter, possibly with a core dump

Description

@serhiy-storchaka
serhiy-storchaka
opened on Jul 22, 2014
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']

    Linked PRs

    Activity

    1. serhiy-storchaka commented on Jul 22, 2014

      @serhiy-storchaka
      serhiy-storchaka
      on Jul 22, 2014
      MemberAuthor

      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
    2. serhiy-storchaka
      added
      extension-modulesC modules in the Modules dir
      type-crashA hard crash of the interpreter, possibly with a core dump
      on Jul 22, 2014

    3. BreamoreBoy commented on Feb 14, 2015

      @BreamoreBoy
      BreamoreBoymannequin
      on Feb 14, 2015
      Mannequin

      Would somebody please review Serhiy's patch.

    4. serhiy-storchaka commented on Feb 14, 2015

      @serhiy-storchaka
      serhiy-storchaka
      on Feb 14, 2015
      MemberAuthor

      Oh, Mark, please stop shaking up bug tracker.

    5. vstinner commented on Mar 31, 2015

      @vstinner
      vstinner
      on Mar 31, 2015
      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.

    6. vstinner commented on Mar 31, 2015

      @vstinner
      vstinner
      on Mar 31, 2015
      Member

      Oh, Mark, please stop shaking up bug tracker.

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

    7. serhiy-storchaka commented on Apr 1, 2015

      @serhiy-storchaka
      serhiy-storchaka
      on Apr 1, 2015
      MemberAuthor

      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.

    8. vstinner commented on Apr 1, 2015

      @vstinner
      vstinner
      on Apr 1, 2015
      Member

      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.

    9. ezio-melotti
      transferred this issue fromon Apr 10, 2022
    10. erlend-aasland
      added this to dbm and shelve issueson Jan 25, 2024

    11. furkanonder commented on May 25, 2025

      @furkanonder
      furkanonder
      on May 25, 2025
      Contributor

      The issue still exists; I can reproduce it on Python 3.15

      $ ./python
Python 3.15.0a0 (heads/main:91b48868a8, May 25 2025, 18:45:04) [GCC 15.1.1 20250425] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import _gdbm as dbm
>>> db = dbm.open('x.db', 'n')
>>> open('x.db', 'wb').close()
>>> db[b'a'] = b'b'
[1]    163083 bus error (core dumped)  ./python

    12. serhiy-storchaka commented on Jun 1, 2025

      @serhiy-storchaka
      serhiy-storchaka
      on Jun 1, 2025
      MemberAuthor

      The fatal_func parameter is deprecated now, so this way should no longer be used. It is expected that new gdbm versions better handle errors and do not need such function.

      The tests, added in dbm_gdbm_fatal_error.patch, fail with unpatched code because it raises different exceptions or do not raise exceptions. But they do not crash. The original example still crashes. The difference is that it uses empty database. Changing the tests to use empty database makes them crashing.

      We can only hope that crashes will be fixed in upstream.

    13. serhiy-storchaka commented on Jun 1, 2025

      @serhiy-storchaka
      serhiy-storchaka
      on Jun 1, 2025
      MemberAuthor

      I have found that using the GDBM_NOMMAP flag prevents these crashes. But it can impact performance and/or memory consumption. I think we cannot expect more.

      We can add support for that flag.

    14. serhiy-storchaka
      self-assigned this
      on Jun 1, 2025

    15. 7 remaining items

    16. serhiy-storchaka
      added a commit that references this issue on Jul 22, 2025

      Revert "pythongh-66234: Add flag to disable the use of mmap in dbm.gnu (

      11dd754

    17. serhiy-storchaka commented on Jul 22, 2025

      @serhiy-storchaka
      serhiy-storchaka
      on Jul 22, 2025
      MemberAuthor

      Sad. So it doesn't work. Then there's no reason to add this flag.

    18. taegyunkim
      added a commit that references this issue on Aug 4, 2025

      pythongh-66234: Add flag to disable the use of mmap in dbm.gnu (pytho…

      fedabab
    19. furkanonder
      moved this from Done to Todo in dbm and shelve issueson Aug 17, 2025
    20. furkanonder
      moved this from Todo to In Progress in dbm and shelve issueson Aug 17, 2025
    21. furkanonder
      added
      stdlibStandard Library Python modules in the Lib/ directory
      triagedThe issue has been accepted as valid by a triager.
      3.13only security fixes
      3.14bugs and security fixes
      3.15bugs and security fixes
      on Aug 17, 2025
    22. Agent-Hellboy
      added a commit that references this issue on Aug 19, 2025

      pythongh-66234: Add flag to disable the use of mmap in dbm.gnu (pytho…

      5ae5b25
    23. serhiy-storchaka
      added a commit that references this issue on Sep 20, 2025

      Revert "gh-66234: Add flag to disable the use of mmap in dbm.gnu (GH-…

      20d5494
    24. serhiy-storchaka
      closed this as completedon Sep 20, 2025
    25. github-project-automation
      moved this from In Progress to Done in dbm and shelve issueson Sep 20, 2025
    26. serhiy-storchaka
      closed this as not plannedon Sep 20, 2025
    Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

    Metadata

    Metadata

    Assignees

    Labels

    3.13only security fixes3.14bugs and security fixes3.15bugs and security fixesextension-modulesC modules in the Modules dirstdlibStandard Library Python modules in the Lib/ directorytriagedThe issue has been accepted as valid by a triager.type-crashA hard crash of the interpreter, possibly with a core dump

    Projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions