I got this error from pop3proxy running on my W2K server :- error: uncaptured python exception, closing channel <sb_smtpproxy.BayesSMTPProxy connected 192.168.1.100:1571 at 0x1833aa8> (bsddb._db.DBRunRecoveryError:(-3098 2, 'DB_RUNRECOVERY: Fatal error, run database recovery -- fatal region error det ected; run recovery') [C:\Python23\lib\asyncore.py|read|69] [C:\Python23\lib\asy ncore.py|handle_read_event|387] [C:\Python23\lib\asynchat.py|handle_read|136] [C :\spambayes-1.0a6\scripts\sb_smtpproxy.py|found_terminator|222] [C:\spambayes-1. 0a6\scripts\sb_smtpproxy.py|onProcessData|318] [C:\spambayes-1.0a6\scripts\sb_sm tpproxy.py|train|433] [C:\spambayes-1.0a6\spambayes\classifier.py|learn|211] [C: \spambayes-1.0a6\spambayes\classifier.py|_add_msg|346] [C:\spambayes-1.0a6\spamb ayes\storage.py|_wordinfoset|270] [C:\Python23\lib\shelve.py|__setitem__|130] [C :\Python23\lib\bsddb\__init__.py|__setitem__|90]) I was attempting to forward the following spam for training (it had been clasified as ham) :- Hey, just got this new toy. Saves me 30% on my gas, proven to work and seen all over the place. Mine paid for itself in 2 weeks. A worthwhile investment, and guaranteed to work. Can't go wrong, go see what I mean. I'll be saving 30% for lfe at the pumps now. Later. http://www.d3kn.org/default.asp?axel=1465 take me 0ff please. http://www.vnmc.org/out1v/pre-rem2e.asp g dfg fd g dfg dg iqydcpnqwsh xhdd lrvxe rad pcw j dljuaxayf sxq ngq vltc uk ksnjqaplfmptwvwlblgma --- mailto:alan@mullen.demon.co.uk http://www.mullen.demon.co.uk/
Alan> I got this error from pop3proxy running on my W2K server :- Alan> error: uncaptured python exception, closing channel Alan> <sb_smtpproxy.BayesSMTPProxy connected 192.168.1.100:1571 at Alan> 0x1833aa8> (bsddb._db.DBRunRecoveryError:(-3098 2, Alan> 'DB_RUNRECOVERY: Fatal error, run database recovery -- fatal Alan> region error detected; run recovery') A number of people have seen this. It appears to be related to incorrect locking of the database in multi-threaded applications. If you're not a programmer that may not make sense to you. The simplest way to work around that may be to switch to the Pickle form of the database. However, before attempting that switch, let us know what version of SpamBayes you are running. Some bugs in the configuration saving code were fixed only recently. Tony's the expert in this area. For the spambayes-dev folks: If we're not properly mediating access to the on-disk version of the DBDictClassifier, we're probably not mediating access to the in-memory PickledClassifier either. Maybe all we need to do is add a little bit of locking to the Classifier class or its subclasses. Skip
Thanks for the quick reply. Its OK, I am a porogrammer, so I do understand what multi-threading is. I am using version 1.06a, which I downloaded a couple of weeks ago. I will try using a pickle. Great product. I am very impressed with it so far. --- mailto:alan@mullen.demon.co.uk http://www.mullen.demon.co.uk/ -----Original Message----- From: Skip Montanaro [mailto:skip@pobox.com] Sent: 30 September 2003 21:12 To: alan@mullen.demon.co.uk Cc: spambayes@python.org; spambayes-dev@python.org Subject: Re: [Spambayes] Error from pop3proxy Alan> I got this error from pop3proxy running on my W2K server :- Alan> error: uncaptured python exception, closing channel Alan> <sb_smtpproxy.BayesSMTPProxy connected 192.168.1.100:1571 at Alan> 0x1833aa8> (bsddb._db.DBRunRecoveryError:(-3098 2, Alan> 'DB_RUNRECOVERY: Fatal error, run database recovery -- fatal Alan> region error detected; run recovery') A number of people have seen this. It appears to be related to incorrect locking of the database in multi-threaded applications. If you're not a programmer that may not make sense to you. The simplest way to work around that may be to switch to the Pickle form of the database. However, before attempting that switch, let us know what version of SpamBayes you are running. Some bugs in the configuration saving code were fixed only recently. Tony's the expert in this area. For the spambayes-dev folks: If we're not properly mediating access to the on-disk version of the DBDictClassifier, we're probably not mediating access to the in-memory PickledClassifier either. Maybe all we need to do is add a little bit of locking to the Classifier class or its subclasses. Skip
[Skip]
... For the spambayes-dev folks: If we're not properly mediating access to the on-disk version of the DBDictClassifier, we're probably not mediating access to the in-memory PickledClassifier either. Maybe all we need to do is add a little bit of locking to the Classifier class or its subclasses.
We don't do any locking in storage.py, mainly because that wasn't intended to be thread-safe. Before trying to make it thread-safe, someone has to identify the specific use cases in which the API has to support concurrent access. I really don't know what they may be, and low-level locking can be very expensive. If it amounts to no more than making training mutually exclusive with scoring, then some gross locks at a higher level would be a lot cheaper. But, so far, nobody has identified a specific sequence of actions leading to DBRunRecoveryError. I'll speculate about one possible problem with Berkeley: if it isn't shut down cleanly, DBRunRecoveryError may well be an *expected* exception when you next start it, and running recovery at such times would then be a normal part of using Berkeley. Until we know what's triggering DBRunRecoveryError, I'm just as inclined to believe it can't be fixed without incorporating recovery as I am to believe it's due to a thread race.
participants (3)
-
Alan Campbell -
Skip Montanaro -
Tim Peters