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/
