https://bugs.exim.org/show_bug.cgi?id=2886
Jeremy Harris <jgh146exb@???> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |ASSIGNED
--- Comment #19 from Jeremy Harris <jgh146exb@???> ---
(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.
--
You are receiving this mail because:
You are on the CC list for the bug.
