Autor: Chris Laif Data: Dla: exim-users Temat: Re: [exim] Sending mail fails (using TLS via company server) since
upgrade to 4.85
On Sun, Aug 16, 2015 at 10:42 PM, Jeremy Harris <jgh@???> wrote: > On 16/08/15 21:08, Chris Laif wrote:
>> Please let me know if you've any idea on how to debug further.
>
> Getting a coredump would help a lot. You'll probably
> need to play with "ulimit -c" and /proc/sys/fs/suid_dumpable
> (see "man 5 core").
>
Thank you for your help. After some hours running with coredumps
enabled, I saw one core dump this afternoon (yesterday there were
hundreds).
# gdb /opt/exim/bin/exim-4.86-7
GNU gdb (Debian 7.7.1+dfsg-5) 7.7.1
[...]
Reading symbols from /opt/exim/bin/exim-4.86-7...(no debugging symbols
found)...done.
(gdb) core /tmp/exim.core.1439805965.29112
warning: core file may not match specified executable file.
[New LWP 29112]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Core was generated by `/opt/exim/bin/exim -Mc 1ZRHIo-0007ZK-V3'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0 0x0000000000475eda in string_copy ()
(gdb) where
#0 0x0000000000475eda in string_copy ()
#1 0x0000000000421852 in deliver_make_addr ()
#2 0x000000000049134b in smtp_local_identity ()
#3 0x000000000049140a in smtp_are_same_identities ()
#4 0x000000000047dc55 in transport_check_waiting ()
#5 0x0000000000494353 in smtp_deliver ()
#6 0x000000000049567f in smtp_transport_entry ()
#7 0x000000000042520e in do_remote_deliveries ()
#8 0x00000000004289e8 in deliver_message ()
#9 0x0000000000432690 in main ()
Interestingly, all mails get delivered to the recipients, the crash
seems to occur after the DATA cmd. Dovecot logs:
lmtp(1728): Info: Disconnect from 10.2.3.4: Connection closed (in DATA finished)
instead of
lmtp(13149): Info: Disconnect from 10.2.3.4: Successful quit
We do not have any complaints about non-delivered mails yet. But we
have lots of frozen messages in the exim queue.
> Bonus points if you can install an exim package with debug
> information, and get a decently readable stacktrace (via gdb).
I'll do that if the above doesn't help, please let me know.
