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 < [email protected]> 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 <= [email protected] H=(AGNIESZKA) [x.x.x.x] I=[x.x.x.x]:25 > P=esmtpa > A=login:[email protected] S=5155019 [email protected] > 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): > ## [email protected] > ## 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): ## [email protected] ## Exim details at http://www.exim.org/ ## Please use the Wiki with this list - http://wiki.exim.org/
