if you look at /dev/kmesg you might find many messages about "checked N page table entries". i think smtpd is getting a trap (probably a null pointer) and because the value returned from catchalarm is the wrong way round, it continues to retry using the bad pointer until the alarm goes off (after a long time), when it breaks (because no note handler has handled the alarm).
i didn't really understand why it was trying to continue after the alarm, rather than logging and quitting. does it not always mean that a caller has connected but hasn't completed a request after a long time? as cinap noted(!) there's a separate problem of what happens if the trap or alarm happens when locks are held, but i think that's less likely to be a problem in practice: an alarm will probably go off when nothing much has happened (ie, the program isn't holding any other lock but waiting for input). it's harder to be sure about bad pointer traps, but if those happen with locks held, i'd suspect those are more likely to be locks unrelated to those needed by syslog and print.
