------- You are receiving this mail because: ------- You are on the CC list for the bug.
http://bugs.exim.org/show_bug.cgi?id=927 Phil Pennock <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |LATER --- Comment #14 from Phil Pennock <[email protected]> 2009-12-11 10:49:42 --- Okay, Christian kindly provided me with access to the corefile. It really is dead on the first line of main(), since the initialisations of the function automatic-scope variables in main() don't happen and they're random garbage. (Unless there's a reason for arg_smtp_receive_timeout to be set to 4812437 via the -os option to Exim). So the segfault is happening during library loading. Is it an artifact of the transfer to the Debian-derivative system that the binary appears to be linked against two different versions of GnuTLS? Both GnuTLS *and* OpenSSL linked into the same binary? I think that: 1: exim queue-runners can run quite often, so if there's much mail in the queue then there's a statistically higher chance of Exim showing up a system problem than some other random process, and queue-runners will be the most frequently run 2: this is dying too soon to be anything wrong in the Exim code 3: you're better off chasing the architecture maintainers to help you diagnose what's going on with the library init and see if there's a way, other than iterating through "linked in feature X but not feature X" to determine which libraries are triggering this? I'm not closing the bug completely yet. Perhaps there's something Exim could be doing better to help prevent this; compiling with some other gcc options on your platform, for instance, but I don't think there's anything the Exim devs can do to help at his time. Sorry. -- Configure bugmail: http://bugs.exim.org/userprefs.cgi?tab=email -- ## List details at http://lists.exim.org/mailman/listinfo/exim-dev Exim details at http://www.exim.org/ ##
