Assertion failed for krb5kdc

Ken Raeburn raeburn at MIT.EDU
Thu Oct 8 04:05:15 EDT 2009


On Oct 8, 2009, at 02:19, Mohammad, Meraj wrote:
> Kerberos 5 release 1.7". I am always getting assertion failure and
> program is aborted.
> I am not getting a stack trace and i have no idea, how to get stack
> trace.

Do you know how to use gdb?
Something like this sequence of commands should work:

At the shell prompt: gdb /path/to/krb5kdc
At the (gdb) prompt: run -n           # <- "-n" tells it not to fork  
into background

After it hits the assertion failure you should get another "(gdb)"  
prompt.  Run the gdb command "bt" (for "backtrace") and send the  
results.

If it doesn't hit the assertion failure when run this way, try "set  
args" (that tells gdb to forget about the "-n" command line argument,  
as "run" without any extra arguments will re-run the program with the  
arguments you used the time before) and then "run" and see if that  
triggers the problem.

Alternatively, if you got a file named "core" in the directory where  
you started the KDC, then "gdb /path/to/krb5kdc /path/to/core" will  
let you examine the memory image of the dead process, so you can run  
the "bt" command without having to start up a new KDC process under  
the debugger.

If you don't have gdb installed and don't know how to get it  
installed, you can try a debugger shipped with Solaris, but I don't  
remember offhand which Solaris 9 might ship with...


Based on the message, my guess is a bug in the library initialization  
code, perhaps triggered by a broken version of pthread_once.  Our  
library jumps through some hoops to try to work with both single- 
threaded and multi-threaded programs (more precisely, programs built  
as multi-threaded programs, which get the thread support library  
linked in, and programs which are built as single-threaded programs,  
which don't) without requiring two different versions of the library.   
However, older version of Solaris included some broken dummy versions  
of thread-support functions which sometimes made it hard to figure out  
which mode was in use.  It may be that some of the tests written to  
detect the Solaris stub versions got broken in 1.7 (or even earlier);  
since MIT's Kerberos group has been using Solaris 10 for testing for  
quite a while, this could've been overlooked for a long time.  (That's  
the sort of thing beta testing is supposed to help uncover, isn't  
it?)  If my guess is right, it probably wouldn't even be hard to fix,  
but the code has grown rather baroque and may take some time to  
understand first...

Ken



More information about the Kerberos mailing list