-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Sander Holthaus - Orange XL writes:
> Steve Martin wrote:
> > Sat Aug 20 00:28:36 2005 [16014] info: spamd: processing
> > message <[EMAIL PROTECTED]> for filter:88
> > Sat Aug 20 00:28:42 2005 [16014] error: __alarm__ Sat Aug 20
> > 00:28:42 2005 [16014] error: __alarm__ Sat Aug 20 00:28:49
> > 2005 [16014] info: spamd: identified spam
> > (35.1/5.0) for filter:88 in 13.7 seconds, 2360 bytes.
> >
> > Anyone know how one might track these down (what debug areas
> > to start with)? I've seen 2 in the last 30 hours or so.
> >
> > Rerunning the same message through with spamc gives the same
> > score, but no __alarm__ messages.
> >
> > SA 3.1rc1
>
> They are quite easy to find in the code. Looking at them, I can only say
> that I don't understand how they get used in the first place. It seems to be
> using the return value of alarm, but I don't have a clue why. It returns the
> value of the previous timer, or 0. But from what I can see and how it us
> used, you only want to set it back to zero.
It is indeed the signal indicating that an alarm() has fired;
alarm() will fire a SIGALRM, the perl signal handler for that
fires a die exception with "__alarm__", and the eval { }
exception-catching block will catch that.
> Next to that, if an eval which has an alarm, fails, the alarm isn't
> imidiately reset, but calls some other code first (
> $permsgstatus->leave_helper_run_mode(); ).
>
> Last, I would say the evals are quite wide. Beside the actual code that
> calls Pyzor/DCC, the also contain or other bits, meaning they can time out
> even though the called app ran succesfull (but took long, but still less
> than the specified timeout by the user).
I don't think that is correct. If you find a specific case,
feel free to open a bug.
- --j.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)
Comment: Exmh CVS
iD8DBQFDB4MqMJF5cimLx9ARApO9AJ4/wqO3krIXKAlRi2YrZLKWuQZCLQCguPb1
MTtdqK/koRAHWVk80bnlDiI=
=XYTX
-----END PGP SIGNATURE-----
