Repository navigation
__del__ in dumbdbm fails under some circumstances #38320
Description
| BPO | 723231 |
|---|---|
| Nosy | @tim-one, @rhettinger |
| Files |
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 = 'https://github.com/tim-one'
closed_at = <Date 2003-07-13.02:23:29.000>
created_at = <Date 2003-04-17.17:02:09.000>
labels = ['library']
title = '__del__ in dumbdbm fails under some circumstances'
updated_at = <Date 2003-07-13.02:23:29.000>
user = 'https://bugs.python.org/timstone4'bugs.python.org fields:
activity = <Date 2003-07-13.02:23:29.000>
actor = 'tim.peters'
assignee = 'tim.peters'
closed = True
closed_date = None
closer = None
components = ['Library (Lib)']
creation = <Date 2003-04-17.17:02:09.000>
creator = 'timstone4'
dependencies = []
files = ['5193']
hgrepos = []
issue_num = 723231
keywords = ['patch']
message_count = 4.0
messages = ['43397', '43398', '43399', '43400']
nosy_count = 3.0
nosy_names = ['tim.peters', 'rhettinger', 'timstone4']
pr_nums = []
priority = 'high'
resolution = 'fixed'
stage = None
status = 'closed'
superseder = None
type = None
url = 'https://bugs.python.org/issue723231'
versions = []Metadata
Metadata
Assignees
Projects
- Status
Activity
timstone4 commentedon Apr 17, 2003
Using dumbdbm for simple testing, I occasionally get the following
error:
Exception exceptions.AttributeError: "'NoneType'
object has no attribute 'error'
" in <bound method
_Database.__del__ of <dumbdbm._Database instance at
0x008B356
8>> ignored
I've tracked it down to a
problem with the releasing of the reference to _os during __del__,
which then calls _commit. _commit proceeds to use the _os,
which is given a value of None... blamo...
rhettinger commentedon Jul 13, 2003
Logged In: YES
user_id=80475
Tim, did you see this during your review of dumbdbm?
tim-one commentedon Jul 13, 2003
Logged In: YES
user_id=31435
I didn't pay attention to it, but it is an obvious shutdown
race. I'll fix it. Tim Stone (the OP) is a contributor to the
spambayes project, and it turns out this is damned important
in spambayes, because it appears the spambayes code never
calls the dumbdbm.close() method explicitly. Something else I
learned from the dumbdbm review is that a dumbdbm's disk
files routinely get out of synch with each other, and rely on
someone calling close() or __del__() to get them back in
synch. If a .bak file doesn't already exist, though, this
shutdown race can prevent __del__() from synch'ing the files.
Boosted priority.
tim-one commentedon Jul 13, 2003
Logged In: YES
user_id=31435
Fixed, in
Lib/dumbdbm.py; rev 1.26
Misc/NEWS; rev 1.810