Kerberos throwing SIGABORT in exit processing
John Hascall
john at iastate.edu
Mon May 12 09:52:03 EDT 2008
> 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
More information about the Kerberos
mailing list