Re: Assertion failure due to repeated K5_KEY_GSS_SPNEGO_STATUS registration.

W dniu 16.10.2020 o 00:55, Greg Hudson pisze:
> On 10/15/20 5:49 PM, Adam Dabrowski wrote:
>> 1. Libgssapi_krb.so.2.2 is loaded dynamically with dlopen.
>> 2. Call to gss_init_sec_context - library initialization, first
>> registration of K5_KEY_GSS_SPNEGO_STATUS.
>> 3. libgssapi_krb.so.2.2 is unloaded, however libkrb5support stays in the
>> process memory.
>> 4. Steps 1., 2..
>> 5. Abort due to failed assertion 'destructors_set[keynum] == 0' in
>> k5_key_register.
> If you edit gss_spnegoint_lib_fini() and add:
>
>          k5_key_delete(K5_KEY_GSS_SPNEGO_STATUS);
>
> does the problem go away?  I think this was neglected in commit
> d160bc733a3dbeb6d84f4e175234ff18738d9f66 .

Yes, as I mentioned in previous mail, I've already tried that and it 
prevents crashes.
I just wasn't sure if empty gss_spnegoint_lib_fini is simple oversight 
or has some rationale
behind it.
_______________________________________________
krbdev mailing list             [email protected]
https://mailman.mit.edu/mailman/listinfo/krbdev