Comment 32 for bug 1974214

(In reply to Andreas Metzler from comment #17)
> Created attachment 1416 [details]
> (unpatched) exim debug output

Thanks Andreas. For this variant, the message is properly transferred
(accepted by the destination on the second MX tried) and then we segv
after the peer has indicated a TLS close.

It'd be useful to peek at a core stack to see if the crash was actually in the
GnuTLS library on some subsequent call into it. The debug trace:

 12:00:14 13972 Calling gnutls_record_recv(session=0x558e5bd826b0, buffer=0x558e5bdb60e8, len=4096)
 12:00:14 13972 GnuTLS<3>: ASSERT: ../../lib/record.c[_gnutls_recv_in_buffers]:1589
 12:00:14 13972 Got TLS_EOF (that read returned empty)

 12:00:14 13972 tls_close(): shutting down TLS (with response-wait)
 12:00:14 13972 tls_write((nil), 0) (zero bytes to write,
                                                should not call into lib here)

 12:00:14 13972 GnuTLS<3>: ASSERT: ../../lib/buffers.c[_gnutls_io_write_flush]:696 (unclear how we got here)

 12:00:14 13972 LOG: MAIN PANIC
 12:00:14 13972 SIGSEGV (fault address: 0x1)

is concerning wrt. that _gnutls_io_write_flush location, but not
definitive as to the location trigerring the segv.