on Thu Jul 26 2007, "Mark Hammond" <mhammond-bte8sPG7QFgW+bLBXbPJGg-AT-public.gmane.org> wrote:
This bug appears to be back in some form: http://sourceforge.net/tracker/index.php?func=detail&aid=13876 99&group_id=61702&atid=498103
Its hard to know if that fix was applied, as there is no attachement with the patch. Hopefully Tony will notice this thread and pipe up.
I was unable to reopen the tracker item. Can someone help me to at least debug this problem? When exceptions are swallowed like that without a backtrace, I don't know where to start.
I'm guessing the vanishing backtrace is due to it being called by __del__. It *looks* like it might be __del__ in sb_filter.py. However, it looks a little like your exception is slightly different than the backtrace in that bug - the bug refers to an error adding tokens to the DB after training, while your exception sounds more like an exception as the DB is closed.
Yes, after hacking __del__ to dump a backtrace, I see: Traceback (most recent call last): File "/usr/local/bin/sb_filter.py", line 185, in __del__ self.close() File "/usr/local/bin/sb_filter.py", line 180, in close self.h.close() File "/usr/local/lib/python2.4/site-packages/spambayes/hammie.py", line 269, in close self.store() File "/usr/local/lib/python2.4/site-packages/spambayes/hammie.py", line 266, in store self.bayes.store() File "/usr/local/lib/python2.4/site-packages/spambayes/storage.py", line 266, in store self._write_state_key() File "/usr/local/lib/python2.4/site-packages/spambayes/storage.py", line 270, in _write_state_key self.db[self.statekey] = (classifier.PICKLE_VERSION, File "/usr/local/lib/python2.4/shelve.py", line 130, in __setitem__ self.dict[key] = f.getvalue() File "/usr/local/lib/python2.4/site-packages/bsddb3/__init__.py", line 218, in __setitem__ self.db[key] = value DBAccessError: (13, 'Permission denied -- put: attempt to modify a read-only tree') My analysis is as follows: HammieFilter.close (in sb_filter.py) jumps through all sorts of hoops to remember the mode in which the DB was opened, and avoid calling store() if it was only opened for read. def close(self): if self.h is not None: if self.mode != 'r': self.h.store() self.h.close() self.h = None So it sorta looks like Tony's patch was applied. However, Hammie.close (in hammie.py) just barrels ahead and calls store() unconditionally... I'm not sure what the right fix here would be. Keep HammieFilter from calling Hammie.close() when the DB was not opened for write? Sink the close/store/mode-checking logic from HammieFilter into Hammie itself? Something else? -- Dave Abrahams Boost Consulting http://www.boost-consulting.com The Astoria Seminar ==> http://www.astoriaseminar.com