On Tue, Oct 24, 2006 at 10:02:04AM -0700, Tim Wilde wrote:
> Chris Lightfoot wrote:
> > I have seen segfaults with exim+TLS on FreeBSD previously,
> > but never tracked down the cause (we didn't need TLS and
> > just switched it off). But can you recompile your exim
> > with debug symbols and get another stack trace?
> >
> > http://www.exim.org/mail-archives/exim-users/Week-of-Mon-20050321/msg00026.html
>
> Stack trace with debug symbols:
[...]
> #12 0x2830b16e in SSL_CTX_use_certificate_chain_file ()
> from /usr/lib/libssl.so.4
> #13 0x080c963e in tls_init (host=0x0, dhparam=0xbfbfda98 "p\001*\b",
> certificate=0x82a0170 "/usr/local/exim/etc/krellis.org.pem",
> privatekey=0x0, addr=0x0) at tls-openssl.c:380
> #14 0x080c9bab in tls_server_start (require_ciphers=0x0) at
> tls-openssl.c:628
> #15 0x080c1fbc in smtp_setup_msg () at smtp_in.c:3370
> #16 0x08080a4b in daemon_go () at daemon.c:495
> #17 0x080910c1 in main (argc=4, cargv=0xbfbfec00) at exim.c:4027
>
> Looks different from what you reported previously. Doesn't tell me much
> more, but hopefully it might give someone else a clue. :)
indeed... the only thing that strikes me there is the
value of dhparam gdb is reporting in the params of
tls_init (it should be an expansion string used to
identify a DH parameters file); either the passed value
was invalid (which seems surprising since by that point
it's been successfully used by init_dh()) or the stack is
being corrupted somewhere along the way.
--
DO NOT DROP ARTICLES FROM BRIDGE
(notice on a bridge in Vancouver; seen on the Internet)
