on Sun Jul 29 2007, David Abrahams <dave-UB3wUj7V41K5azolltMz9laTQe2KTcn/-AT-public.gmane.org> wrote:
> 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? Okay, I submitted a simple patch. I hope someone can look it over. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com The Astoria Seminar ==> http://www.astoriaseminar.com _______________________________________________ spambayes-dev mailing list spambayes-dev@python.org http://mail.python.org/mailman/listinfo/spambayes-dev
