On 28/07/2021 14:58, Matthew Frost via Exim-users wrote:
Core file '/var/spool/exim/core.exim-4.95-RC0-2.40.42328.core' (x86_64) was loaded. (lldb) bt exim-4.95-RC0-2 was compiled with optimization - stepping may behave oddly; variables may not be available. * thread #1, name = 'exim-4.95-RC0-2', stop reason = signal SIGBUS * frame #0: 0x00000000002cdb46 exim-4.95-RC0-2`smtp_start_session [inlined] string_from_gstring(g=0x2000000801a469ec) at functions.h:919:4 [opt] frame #1: 0x00000000002cdb41 exim-4.95-RC0-2`smtp_start_session at smtp_in.c:3090 [opt]
Something is very different between a FreeBSD jail and normality. This is very basic stuff, well exercised (including in our FreeBSD buildfarm systems, which run the regression testsuite, but do not use jails as far as I know). We're just finishing off building the SMTP banner message prior to sending it. I assume your config isn't doing anything odd in that region? If not, we'd need a non-optimised build to get a coredump we can look at C variables in.
Core file '/var/spool/exim/core.exim-4.95-RC0-2.40.42413.core' (x86_64) was loaded. (lldb) bt exim-4.95-RC0-2 was compiled with optimization - stepping may behave oddly; variables may not be available. * thread #1, name = 'exim-4.95-RC0-2', stop reason = signal SIGSEGV * frame #0: 0x00000000002cdb8b exim-4.95-RC0-2`smtp_start_session [inlined] tfo_in_check at smtp_in.c:2437:11 [opt] frame #1: 0x00000000002cdb8b exim-4.95-RC0-2`smtp_start_session at smtp_in.c:3096 [opt]
This is doing less-common getsockopt() operations. If it weren't for the above symptom showing up I'd be more suspicious. For now I suggest we ignore it (we could hack the code, commenting out the single call to tfo_in_check() if needed).
Core file '/var/spool/exim/core.exim-4.95-RC0-2.40.42645.core' (x86_64) was loaded. (lldb) bt * thread #1, name = 'exim-4.95-RC0-2', stop reason = signal SIGSEGV * frame #0: 0x0000000000000000 frame #1: 0x00000000002619e0 exim-4.95-RC0-2 at daemon.c:63:1 frame #2: 0x0000000000260ff1 exim-4.95-RC0-2`daemon_go at daemon.c:528:8 [opt] frame #3: 0x0000000000260eca exim-4.95-RC0-2`daemon_go at daemon.c:2594 [opt]
daemon.c:2594 - daemon_go() calls handle_smtp_call() daemon.c:528:8 - handle_smtp_call() calls smtp_start_session() daemon.c:63:1 - appears to be in sighup_handler() I suppose that's a feasible stack if we really did get a HUP. But that handler is as simple as they come; I'm really starting to distrust your environment now. I wonder if the introduction of readonly-config is a factor? Test for this by adding #define MISSING_POSIX_MEMALIGN to your OS/os.h-FreeBSD and running that build. And, if there's a FreeBSD afficionado out there willing to set up, maintain and monitor a FreeBSD with-jails buildfarm animal we might catch such issues earlier. Right now we have the choice of delaying the release or declaring FreeBSD not-supported. -- Cheers, Jeremy -- ## List details at https://lists.exim.org/mailman/listinfo/exim-users ## Exim details at http://www.exim.org/ ## Please use the Wiki with this list - http://wiki.exim.org/