Kerberos throwing SIGABORT in exit processing

[John Hascall]

> Interesting... does this happen reproducibly?

Yes.  Every time.

> I've seen reports of crashes in the thread support before, but aside  
> from a race condition Ezra reported (is this program multithreaded?),  
> mostly they seem to do with programs that load multiple versions of  
> the com_err library and I guess finalization code for one gets run  
> without it having been properly initialized, or something.  Can you  
> give me some more details on this case?  For example, what libraries  
> are getting loaded by this program?

It is not a threaded program.  It is possible that there is
some com_err evilness -- lord knows the API change there has
been a big pita before!

Anyway, ldd says:
/usr/athena/etc/update_server:
        -lresolv.1 => /usr/lib/libresolv.so.1
        -lkrb5support => /usr/athena/lib/libkrb5support.so
        -lk5crypto => /usr/athena/lib/libk5crypto.so
        -lcom_err => /usr/athena/lib/libcom_err.so
        -lkrb5 => /usr/athena/lib/libkrb5.so
        -lcrypt.0 => /usr/lib/libcrypt.so.0
        -lutil.7 => /usr/lib/libutil.so.7
        -lroken.12 => /usr/lib/libroken.so.12
        -lpthread.0 => /usr/lib/libpthread.so.0
        -lc.12 => /usr/lib/libc.so.12

where /usr/athena/lib/lib{krb5support,k5crypto,com_err,krb5}.so
are all the ones built in krb5.1.6.3

> I don't recall if gdb on i386-netbsd supports hardware watchpoints,  
> but if it does, could you trace changes to "key_lock" in util/support/ 
> threads.c and see if it's maybe getting destroyed more than once?

I will attempt to figure this out, thanks.

John