------- You are receiving this mail because: -------
You are on the CC list for the bug.
http://bugs.exim.org/show_bug.cgi?id=927
--- Comment #6 from Phil Pennock <exim-dev@???> 2009-12-09 01:58:16 ---
Note that
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=553503 shows two
full backtraces, with the problem happening in *different* locations, which is
what makes me somewhat suspicious of the RAM.
The other obvious option would be that it's timing related and connected to
SIGALRM handling having been established; I don't recall if timer expiry
persists across an exec() and if this might be tied to an earlier signal set
up? Otherwise, it still seems unlikely that statbuf would be so bogus by the
time SIGALRM is rigged to actually fire.
sigalrm_handler() sets its signal handler parameter to itself (to shut up
compilers) which should be safe (int assignment) and sets sigalrm_seen true.
Now, sigalrm_seen is volatile BOOL, where BOOL is an int.
On a 64-bit platform, that might be iffy.
What happens if src/globals.c is edited, around line 1066:
volatile BOOL sigalrm_seen = FALSE;
to change that to:
volatile sig_atomic_t sigalrm_seen = FALSE
?
-Phil
--
Configure bugmail:
http://bugs.exim.org/userprefs.cgi?tab=email
