On 06/08/2024 00:03, Jim Pazarena via Exim-users wrote:
> 2024-08-05 10:56:02.363 [34521] ---
> 2024-08-05 10:56:02.365 [34521] 0x42de36 <stackdump+0x21> at /u/exim/bin/exim
> 2024-08-05 10:56:02.365 [34521] 0x42df6e <segv_handler+0x5c> at /u/exim/bin/exim
> 2024-08-05 10:56:02.365 [34521] 0x82aca441f <pthread_sigmask+0x54f> at /lib/libthr.so.3
> 2024-08-05 10:56:02.366 [34521] 0x82aca39cb <pthread_setschedparam+0x84b> at /lib/libthr.so.3
> 2024-08-05 10:56:02.366 [34521] ---
Not very much... From the "handling incoming connection" note we must (for the common setup,
where Exim operates the daemon process) have accepted a connection and forked a receive-handler
process. Even for less-common configurations, we expect that stack backtrace to run back
all the way to main(). That is does not is concerning; I start to wonder about the hardware
reliability.
On the other hand, it might also be giving up at the signal-handler boundary. Ot shouldn't
do that either but if it did then that chunk tells us nothing.
We really do want that gdb run.
--
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/
