Bug 4085 - [review] "Sec too small"/"Sec too big" warnings during mass-check
Summary: [review] "Sec too small"/"Sec too big" warnings during mass-check
Status: RESOLVED FIXED
Alias: None
Product: Spamassassin
Classification: Unclassified
Component: Masses (show other bugs)
Version: SVN Trunk (Latest Devel Version)
Hardware: Other other
: P5 normal
Target Milestone: 3.0.4
Assignee: SpamAssassin Developer Mailing List
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2005-01-17 08:28 UTC by Theo Van Dinter
Modified: 2005-05-19 08:37 UTC (History)
0 users


Attachment Type Modified Status Actions Submitter/CLA Status
suggested patch patch None Theo Van Dinter [HasCLA]
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Theo Van Dinter 2005-01-17 08:28:11 UTC 
This probably isn't SA specifically, but I wanted to open a ticket about it
anyway.  I just moved my mass-check runs to a new machine, and receive these
warnings during the run.  Doing a quick Google search, they seem to be generated
by Time::Local, but I'm not sure what is going on to cause the problem.

Sec too small - 24855 < 74752
Sec too big - 24855 > 11647
status:  10% ham: 0      spam: 18523  date: 2004-12-31   now: 2005-01-17 05:20:24
Day too big - 24856 > 24855
Sec too small - 24856 < 74752
Sec too big - 24856 > 11647
status:  20% ham: 0      spam: 37046  date: 2004-12-14   now: 2005-01-17 05:27:32
Sec too small - 24855 < 74752
Sec too big - 24855 > 11647
status:  30% ham: 0      spam: 55569  date: 2004-11-29   now: 2005-01-17 05:34:35
Sec too small - 24855 < 74752
Sec too big - 24855 > 11647
Sec too small - 24855 < 74752
Sec too big - 24855 > 11647
status:  40% ham: 0      spam: 74092  date: 2004-11-12   now: 2005-01-17 05:41:46
Sec too small - 24855 < 74752
Sec too big - 24855 > 11647
Comment 1 Theo Van Dinter 2005-01-17 08:45:47 UTC 
BTW: Time::Local on the new box is 1.1, on the old box it's 1.04.
Comment 2 Theo Van Dinter 2005-01-23 10:13:14 UTC 
The problem seems to occur when the date in question causes a 32-bit overflow. 
ie: the resulting timestamp is > 2**31 or < -(2**31).  This is easy to reproduce
by setting a date string to a large/low year (>2038 or <1902).
Comment 3 Theo Van Dinter 2005-01-23 17:34:19 UTC 
Created attachment 2620 [details]
suggested patch

committed to trunk, r126253

applies to 3.0 as well
Comment 4 Daryl C. W. O'Shea 2005-04-24 19:40:22 UTC 
+1
Comment 5 Michael Parker 2005-04-27 13:58:43 UTC 
Move to 3.0.4 milestone.
Comment 6 Justin Mason 2005-05-19 16:21:48 UTC 
+1
Comment 7 Theo Van Dinter 2005-05-19 16:37:19 UTC 
committed, r171015