Thank you Jeremy for providing a thorough analysis. At present, I have
successfully persuaded the user to implement TLS and port 465 for mail
submission.
Additionally, I have activated core dumps. As soon as I get one I will try
to feed it to gdb (provided that changing the port does not bypass the
problem).
Regards,
Mateusz
wt., 6 lut 2024 o 17:58 Jeremy Harris via Exim-users <
exim-users@???> napisał(a):
> On 2/6/24 08:55, Mateusz Krawczyk via Exim-users wrote:
> > 10:50:46 275444 flushing headers buffer
> > 10:50:46 275444 writing data block fd=8 size=8189 timeout=300
> > 10:50:46 275444 tls_write(0xfcf658, 8189)
> > 10:50:46 275444 SSL_write(0x119ac20, 0xfcf658, 8189)
> > 10:50:46 275444 outbytes=8189 error=0
> > 10:50:46 LOG: MAIN PANIC
> > 10:50:46 SIGSEGV (fault address: 0x4)
> > 10:50:46 275444 flushing headers buffer
> > 10:50:46 275444 writing data block fd=8 size=8189 timeout=300
> > 10:50:46 275444 tls_write(0xfcf658, 8189)
> > 10:50:46 LOG: MAIN PANIC
> > 10:50:46 SIGSEGV (null pointer indirection)
> > 10:50:46 275444 SSL_write(0x119ac20, 0xfcf658, 8189)
> > 10:50:46 LOG: MAIN PANIC
> > 10:50:46 SIGSEGV (275431 handling incoming connection from (AGNIESZKA)
> > [x.x.x.x] I=[x.x.x.x]:25
> > 10:50:46 )
>
> There seems to be two processes mixed up, here. One is writing a message
> out, which implies a transport process running the smtp transport
> (and, wow, that message seems to have a large amount of headers content).
>
> The other one is receiving an inbound message - note the different PID)
> and SEGV'd from a null-pointer indirection. It's that one we're
> interested in.
> Most of the debug lines for that don't seem to include a PID;
> the obvious one before the SIGSEGV are
>
> 10:50:46 Renaming spool header file:
> /var/spool/exim//input/i/1rWvci-000000019eR-2FFn-H
> 10:50:46 Size of headers = 644
> 10:50:46 LOG: MAIN
> 10:50:46 <= xxx@??? H=(AGNIESZKA) [x.x.x.x] I=[x.x.x.x]:25
> P=esmtpa
> A=login:xxx@??? S=5155019 id=009d01da5818$c9a3de30$5ceb9a90$@???
> T="Test message"
>
> That "<=" log line at least gives us a place in receive.c we know
> we got as far as. We don't seem to have gotten as far as sending an SMTP
> response (I'd expect a debug line for that) - sos the suspect code range
> is not too long (4383 - 4521 in my working copy)
>
>
> We're not getting much info from the self-produced stack backtrace;
> almost certainly the compile was not including debug info ("cc -ggdb")
> and may even have been stripped. A pity. Are you set up for getting
> coredump files? If so, please feed one to gdb and see if it's any
> better for a stack backtrace ("bt").
> If not - could you?
>
> (The "libpthread" function in the stack is interesting... perhaps that's
> an artifact of handling the SIGSEGV though)
>
>
> --
> Cheers,
> Jeremy
>
> --
> ## subscription configuration (requires account):
> ##
> https://lists.exim.org/mailman3/postorius/lists/exim-users.lists.exim.org/
> ## unsubscribe (doesn't require an account):
> ## exim-users-unsubscribe@???
> ## Exim details at http://www.exim.org/
> ## Please use the Wiki with this list - http://wiki.exim.org/
>
--
## subscription configuration (requires account):
##
https://lists.exim.org/mailman3/postorius/lists/exim-users.lists.exim.org/
## unsubscribe (doesn't require an account):
## exim-users-unsubscribe@???
## Exim details at
http://www.exim.org/
## Please use the Wiki with this list -
http://wiki.exim.org/
