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
Comments
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 |
Would somebody please review Serhiy's patch. |
Oh, Mark, please stop shaking up bug tracker. |
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. |
I agree: please stop posting useless messages, and review patches instead. |
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. |
2015-04-01 10:39 GMT+02:00 Serhiy Storchaka <report@bugs.python.org>:
I don't think that it's a good practice to try to workaround bugs. IMO |
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:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: