http://bugzilla.spamassassin.org/show_bug.cgi?id=3651
Summary: [patch] Fix "oops! still tied to bayes DBs, untie'ing"
with compile_now
Product: Spamassassin
Version: SVN Trunk (Latest Devel Version)
Platform: Other
OS/Version: FreeBSD
Status: NEW
Severity: major
Priority: P3
Component: Libraries
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]
Numerous folks (including me) have reported odd warnings of "oops! still tied to
bayes DBs, untie'ing". I noticed the same behaviour when invoking SA from
MIMEDefang. With some additional debug statements, I was able to track the
source of the error down to compile_now(), which MIMEDefang calls by default in
mimedefang-filter.
So, this is quite reproducable; simply call compile_now() with Bayes enabled.
compile_now() neatly cleans up the $status and $mail objects, but doesn't do
anything to close or untie the learner. So, when it calls
sanity_check_is_untied() several lines later, the "oops!" warning is *always*
tripped. One solution is to simply call $self->finish_learner():
--- SpamAssassin.pm.orig Thu Jul 29 23:46:10 2004
+++ SpamAssassin.pm Thu Jul 29 23:58:04 2004
@@ -1128,6 +1128,7 @@
$self->{conf}->{use_bayes_rules} = $use_bayes_rules_value;
$status->finish();
$mail->finish();
+ $self->finish_learner();
# load SQL modules now as well
my $dsn = $self->{conf}->{user_scores_dsn};
I opted to leave the sanity_check_is_untied() call in, although the current
logic implies it shouldn't be needed, since finish_learner() unties everything.
AFAICT, the only other place sanity_check_...() is called from is
PerMsgStatus::Learn, and in that case, it's called right after finish_learner(),
so it should again be serving its intended purpose.
Simple fix... but this certainly took a while to track down.
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
