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/
