On Thu, Jul 29, 2021 at 9:35 PM Jeremy Harris via Exim-users <
exim-users@???> 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 '^$|^.*#' :-)
