Ok, I'm happy to take on trying to create a way to reliably reproduce the
problem. Thanks for the help, will cycle back when I have something.

On Fri, Jan 10, 2020, 2:26 AM Greg Hudson via RT <rt@krbdev.mit.edu> wrote:

> There are some theoretically possible execution paths along those lines
> that
> could lead to the assertion failure, but they don't seem likely to be the
> cause
> of the assertion failures you're seeing.
>
> I don't think the interruption scenario is plausible. SIGKILL would abort
> the
> process immediately (no library unloading), as would any unhandled signal.
> If a
> signal arrived, was handled, and the handler returned, the initializer
> would
> continue running and would finish registering all of the keys. Signal
> handlers
> are not allowed to call exit(). Signal handlers are allowed to call
> _exit(),
> but that would bypass library unloading. On top of that, the "graceful
> reload
> or restart" operation would not seem likely to send a signal to processes
> while
> they are in the middle of initializing the GSSAPI library.
>
> The failed initializer scenario actually kind of tracks, because of a bug
> in
> gssint_mechglue_init() (
>
> https://github.com/krb5/krb5/blob/master/src/lib/gssapi/mechglue/g_initialize.c#L106
> ) where error values can be ignored. (If errors were correctly handled, the
> INITIALIZER_RAN() guard in gssint_mechglue_fini() would not consider the
> initializer to have run because it returned an error.) But I don't think
> this
> is a likely scenario for two reasons. First, you say you're not using
> krb5, and
> gssint_mechglue_init() doesn't actually run until a GSSAPI function is
> invoked.
> (It's possible that the PHP module invokes a GSSAPI function when it
> starts up,
> I guess.) Second, failures inside gss_krb5int_lib_init() should be
> vanishingly
> uncommon; one doesn't really expect mutex initialization to fail.
>
> I will fix the bug in gssint_mechglue_init(), but to diagnose the actual
> problem with any confidence, either I need to be able to reproduce the
> problem,
> or someone who reliably sees the problem needs to debug it in situ, likely
> by
> adding a bunch of instrumentation to the initializer and finalizer code.
>
>
>