Bug 5547

Summary:	calculate_expire_delta return value in BayesStore SQL.pm causes Perl warning
Product:	Spamassassin	Reporter:	Peter Fritz <peter>
Component:	spamassassin	Assignee:	SpamAssassin Developer Mailing List <dev>
Status:	NEW ---
Severity:	trivial
Priority:	P5
Version:	SVN Trunk (Latest Devel Version)
Target Milestone:	Undefined
Hardware:	Other
OS:	All
Whiteboard:
Attachments:	Change return value of BayesStore/SQL.pm::calculate_expire_delta to empty hash

Description Peter Fritz 2007-07-04 07:14:17 UTC

The calculate_expire_delta function in BayesStore/SQL.pm can return undef, 
which creates a warning (turns up in procmail logs):
warn: Odd number of elements in hash assignment at BayesStore.pm line 322.
warn: Use of uninitialized value in list assignment at BayesStore.pm line 322.

It should probably return an empty hash at that point (as per the patch), since
 %delta may have information in it by that stage which we don't want to return, 
since the function didn't complete.

Also need to make sure that the expected behaviour of "return 0 unless 
(%delta);" is maintained in BayesStore.pm, after this call is made:
my %delta = $self->calculate_expire_delta($vars[10], $start, $max_expire_mult);

Relevant dbg output - note the trigger is the SQL connection going away (not 
sure why, since the email still gets scored with bayes):
[32655] dbg: bayes: can't use estimation method for expiry, unexpected result, 
calculating optimal atime delta (first pass)
[32655] dbg: bayes: expiry max exponent: 9
[32655] dbg: bayes: calculate_expire_delta: SQL error: Lost connection to MySQL 
server during query
[32655] warn: Odd number of elements in hash assignment at /perl/lib/Mail/
SpamAssassin/BayesStore.pm line 322.
[32655] warn: Use of uninitialized value in list assignment at /perl/lib/Mail/
SpamAssassin/BayesStore.pm line 322.
[32655] dbg: bayes: atime token reduction
[32655] dbg: bayes: ======== ===============
[32655] dbg: bayes: 43200 0
[32655] dbg: bayes: 86400 0
[32655] dbg: bayes: 172800 0
[32655] dbg: bayes: 345600 0
[32655] dbg: bayes: 691200 0
[32655] dbg: bayes: 1382400 0
[32655] dbg: bayes: 2764800 0
[32655] dbg: bayes: 5529600 0
[32655] dbg: bayes: 11059200 0
[32655] dbg: bayes: 22118400 0
[32655] dbg: bayes: couldn't find a good delta atime, need more token 
difference, skipping expire
[32655] dbg: bayes: set_last_expire: SQL error: MySQL server has gone away
[32655] dbg: bayes: remove_running_expire_tok: SQL error: MySQL server has gone 
away
[32655] dbg: bayes: expiry completed

Output of sa-learn --dump magic for reference:
0.000          0          3          0  non-token data: bayes db version
0.000          0       3215          0  non-token data: nspam
0.000          0       5188          0  non-token data: nham
0.000          0     174856          0  non-token data: ntokens
0.000          0 1163584595          0  non-token data: oldest atime
0.000          0 1183554698          0  non-token data: newest atime
0.000          0          0          0  non-token data: last journal sync atime
0.000          0 1183472725          0  non-token data: last expiry atime
0.000          0   13725329          0  non-token data: last expire atime delta
0.000          0          0          0  non-token data: last expire reduction 
count

Comment 1 Peter Fritz 2007-07-04 07:16:36 UTC

Created attachment 4031 [details]
Change return value of BayesStore/SQL.pm::calculate_expire_delta to empty hash

Comment 2 Peter Fritz 2007-09-28 17:59:14 UTC

If possible, could this trivial patch be reviewed for 3.2.4?  In the mean time I
have been manually patching local installations and the patch resolves the
warning.  See also #5661 related to SQL.pm.  Cheers.

(In reply to comment #0)
> The calculate_expire_delta function in BayesStore/SQL.pm can return undef, 
> which creates a warning (turns up in procmail logs):
> warn: Odd number of elements in hash assignment at BayesStore.pm line 322.
> warn: Use of uninitialized value in list assignment at BayesStore.pm line 322.
> 
> It should probably return an empty hash at that point (as per the patch), since
>  %delta may have information in it by that stage which we don't want to return, 
> since the function didn't complete.
> 
> Also need to make sure that the expected behaviour of "return 0 unless 
> (%delta);" is maintained in BayesStore.pm, after this call is made:
> my %delta = $self->calculate_expire_delta($vars[10], $start, $max_expire_mult);
>