On Thu, Jul 29, 2021 at 9:35 PM Jeremy Harris via Exim-users < [email protected]> wrote:
> 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. > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ The Penguin has sponsored our destruction! :-) I am NOT running inside a jail. What should I do to replicate what he's doing? Actually, Matthew, would you like me to give you access to my FreeBSD 13, so that you can try and reproduce this? Declaring FreeBSD not-supported is an abomination :-) -- Best regards, Odhiambo WASHINGTON, Nairobi,KE +254 7 3200 0004/+254 7 2274 3223 "Oh, the cruft.", egrep -v '^$|^.*#' :-) -- ## 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/
