http://bugzilla.spamassassin.org/show_bug.cgi?id=4415
[EMAIL PROTECTED] changed:
What |Removed |Added
----------------------------------------------------------------------------
Attachment #2982 is|0 |1
obsolete| |
------- Additional Comments From [EMAIL PROTECTED] 2005-09-08 20:30 -------
Created an attachment (id=3122)
--> (http://bugzilla.spamassassin.org/attachment.cgi?id=3122&action=view)
possible fix
ok, here's a possible fix...
Basically, there are a number of spots where the alarm isn't cleared up
*immediately* after the eval {...}; blocks.
Instead in a few of these cases, there's a few lines of code between the end of
eval {...} and the "alarm $oldalarm;" line. This leaves a race condition,
where the code in eval {...}; could have failed for some reason, and in the
intervening code before the alarm cleanup, the alarm fires. The result of that
would be "__alarm__" in the logs, and the mail getting passed through
unscanned.
This patch fixes that, by resetting "alarm $oldalarm" immediately after every
eval {...} block and failure point, instead of at later points; it also sets
$oldalarm = undef; after doing this to avoid double-resetting.
it relies on alarm always returning a defined value, but that appears to be the
case.
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
