Re: libpq crashing on macOS during connection startup

John DeSoi <john(at)desoi(dot)dev> writes:
>> On Nov 30, 2023, at 7:53 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> Ugh, not only Heimdal but a very obsolete version thereof? It borders
>> on negligence for the homebrew PG package to be building against that.
>> They should be pulling in homebrew's MIT Kerberos package and using
>> that, if they want to enable GSSAPI.

> I was looking at the homebrew source for PostgreSQL package to see if there was a way to customize the build options. I did not find one but saw the comment below. Apparently this is a known issue and it was suggested to use the MIT Kerberos package 4 years ago. Instead they just added this comment in 2020.

> # GSSAPI provided by Kerberos.framework crashes when forked.
> # See https://github.com/Homebrew/homebrew-core/issues/47494.

Oh, thanks for finding that. But you misinterpreted the outcome;
the commit that closed that thread did

+# GSSAPI provided by Kerberos.framework crashes when forked.
+# See https://github.com/Homebrew/homebrew-core/issues/47494.
+depends_on "krb5"

The "depends_on" was evidently meant to force building against krb5,
and I suppose it did have that effect when committed. Could they
have done something since then to break it?

Looking closer, your stack trace seems to show that libpq *is*
linked against MIT Kerberos: at least, control flows from
libpq.5.dylib to libgssapi_krb5.2.2.dylib, which is not a
library that Apple supplies. However, then a few subroutines
further deep, we somehow end up in Apple's Kerberos framework,
and that eventually calls libdispatch which is the source of
the problem according to the discussion in issues/47494.

My guess at this point is that somebody at Homebrew put in a
hack (perhaps quite recently) that causes their build of MIT
Kerberos to sometimes call Apple's implementation, and that
ill-advised idea has re-opened the problem that issues/47494
meant to solve.

I'd suggest filing a bug against Homebrew's krb5 package.
Whatever this is, it seems pretty clear that it's not a
Postgres bug.

regards, tom lane