Created attachment 1516988 [details]
File: backtrace

Created attachment 1516989 [details]
File: cgroup

Created attachment 1516990 [details]
File: core_backtrace

Created attachment 1516991 [details]
File: cpuinfo

Created attachment 1516992 [details]
File: dso_list

Created attachment 1516993 [details]
File: environ

Created attachment 1516994 [details]
File: limits

Created attachment 1516995 [details]
File: maps

Created attachment 1516996 [details]
File: mountinfo

Created attachment 1516997 [details]
File: open_fds

Created attachment 1516998 [details]
File: proc_pid_status

Created attachment 1516999 [details]
File: var_log_messages

This message is a reminder that Fedora 29 is nearing its end of life.
Fedora will stop maintaining and issuing updates for Fedora 29 on 2019-11-26.
It is Fedora's policy to close all bug reports from releases that are no longer
maintained. At that time this bug will be closed as EOL if it remains open with a
Fedora 'version' of '29'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 29 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Oh, this issue is quite strange. Deep inside ldap library it crashes on kerberos assertion. I cannot say I understand how it hit such state. But anyway, I think this might be more related to bind-dyndb-ldap issue.

Do you think you can identify this issue and whether it is already fixed? It happened just long time ago.

It fails inside krb5 memory ccache routine. Robbie, if you have any idea how to address that in bind-dyndb-ldap, I'm all ears.

bind-dyndb-ldap uses LDAP bind with Cyrus-SASL via ldap_sasl_interactive_bind_s() this way:

        case AUTH_SASL:
                CHECK(setting_get_str("sasl_mech", ldap_inst->local_settings,
                                      &sasl_mech));
                if (strcmp(sasl_mech, "GSSAPI") == 0) {
                        CHECK(setting_get_str("krb5_principal",
                                              ldap_inst->local_settings,
                                              &krb5_principal));
                        CHECK(setting_get_str("krb5_keytab",
                                              ldap_inst->local_settings,
                                              &krb5_keytab));
                        LOCK(&ldap_inst->kinit_lock);
                        result = get_krb5_tgt(ldap_inst->mctx,
                                              krb5_principal,
                                              krb5_keytab);
                        UNLOCK(&ldap_inst->kinit_lock);
                        if (result != ISC_R_SUCCESS)
                                return ISC_R_NOTCONNECTED;
                }

                log_debug(4, "trying interactive bind using '%s' mechanism",
                          sasl_mech);
                ret = ldap_sasl_interactive_bind_s(ldap_conn->handle, NULL,
                                                   sasl_mech,
                                                   NULL, NULL, LDAP_SASL_QUIET,
                                                   ldap_sasl_interact,
                                                   ldap_inst);
                break;

where get_krb5_tgt() creates in-memory CCACHE and sets its name in KRB5CCNAME environmental variable. One strange thing is that it does
        /* get credentials cache */
        CHECK(str_new(mctx, &ccname));
        CHECK(str_sprintf(ccname, "MEMORY:_ld_krb5_cc_%s", principal));
        ret = setenv("KRB5CCNAME", str_buf(ccname), 1);

        krberr = krb5_cc_resolve(context, str_buf(ccname), &ccache);
        krberr = krb5_kt_resolve(context, keyfile, &keytab);
        krberr = krb5_get_init_creds_keytab(context, &my_creds, kprincpw,
                                            keytab, 0, NULL, &options);
        krberr = krb5_cc_initialize(context, ccache, kprincpw);
        krberr = krb5_cc_store_cred(context, ccache, &my_creds);

and then upon completion it clears them all:
        if (ccache) krb5_cc_close(context, ccache);
        if (keytab) krb5_kt_close(context, keytab);
        if (kprincpw) krb5_free_principal(context, kprincpw);
        if (my_creds_ptr) krb5_free_cred_contents(context, my_creds_ptr);
        if (context) krb5_free_context(context);

So even with successful acquisition the ccache will be destroyed and for in-memory ccache we'll get the ccache destroyed, its content emptied if no other references exist to it. I can definitely see cases when there are no other threads referencing the same ccache anymore.

Fedora 29 changed to end-of-life (EOL) status on 2019-11-26. Fedora 29 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.

This bug was accidentally closed due to a query error. Reopening.

This looks very similar to https://bugzilla.redhat.com/show_bug.cgi?id=1633089 and a few others like it.  I think these were due to a bug in our handling of memory ccache access by multiple handles concurrently - this has since been fixed, so I'm going to close this out (fixed by 146dadec8fe7ccc4149eb2e3f577cc320aee6efb and then later by moving to a new design in 088ba228acce4fd55bbb7c30122fe2703b8beeb8 )

In general, traces that hit an assertion below k5_mutex_lock() are indicative of corruption of some kind.  The lock structure is clobbered with garbage (in this case, by being reallocated), and glibc's sentinel is overwritten.