Assertion failed for krb5kdc
Mohammad, Meraj
When I tried to execute below command in sun Solaris operation
system(version 9). Why I am getting Assertion fail error.
/usr/local/sbin/krb5kdc
Assertion failed: k5int_i->did_run != 0, file krb5_libinit.c, line 63
But /usr/local/sbin/kadmind command working fine for me .
Please help for the same
Regards
Meraj Alam
Tom Yu
> Hi,
>
>
>
> When I tried to execute below command in sun Solaris operation
> system(version 9). Why I am getting Assertion fail error.
>
> /usr/local/sbin/krb5kdc
>
> Assertion failed: k5int_i->did_run != 0, file krb5_libinit.c, line 63
>
>
>
> But /usr/local/sbin/kadmind command working fine for me .
What release of krb5? Does it always have an assertion failure, or
only sometimes? Are you able to get a stack trace?
Mohammad, Meraj
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.
Regards
Meraj Alam
Ken Raeburn
> 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
eightball
output is the same between 8 and 9, so I am just sending 8.
Thanks for your help,
Steve
[root@localhost]/local/BuildArea/krb5/krb5-1.7/src#gdb kdc/krb5kdc
GNU gdb 5.3
Copyright 2002 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and
you are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for
details.
This GDB was configured as "sparc-sun-solaris2.8"...
(gdb) run -n
Starting program: /local/BuildArea/krb5/krb5-1.7/src/kdc/krb5kdc -n
Assertion failed: k5int_i->did_run != 0, file krb5_libinit.c, line 63
Program received signal SIGABRT, Aborted.
0xfef9fe08 in _libc_kill () from /usr/lib/libc.so.1
(gdb) bt
#0 0xfef9fe08 in _libc_kill () from /usr/lib/libc.so.1
#1 0xfef35a2c in abort () from /usr/lib/libc.so.1
#2 0xfef35cd0 in _assert () from /usr/lib/libc.so.1
#3 0xff21716c in krb5int_initialize_library () at krb5_libinit.c:63
#4 0xff2496b4 in init_common (context=0xffbef8d4, secure=0, kdc=1) at
init_ctx.c:134
#5 0x00020370 in main (argc=2, argv=0xffbef94c) at main.c:855
(gdb) The program is running. Exit anyway? (y or n) y
[root@localhost]/local/BuildArea/krb5/krb5-1.7/src#gdb appl/bsd/
klogind
GNU gdb 5.3
Copyright 2002 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and
you are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for
details.
This GDB was configured as "sparc-sun-solaris2.8"...
(gdb) run
Starting program: /local/BuildArea/krb5/krb5-1.7/src/appl/bsd/klogind
Assertion failed: k5int_i->did_run != 0, file error_message.c, line
293
Program received signal SIGABRT, Aborted.
0xff09fe08 in _libc_kill () from /usr/lib/libc.so.1
(gdb) bt
#0 0xff09fe08 in _libc_kill () from /usr/lib/libc.so.1
#1 0xff035a2c in abort () from /usr/lib/libc.so.1
#2 0xff035cd0 in _assert () from /usr/lib/libc.so.1
#3 0xff3411b0 in add_error_table (et=0x187b0) at error_message.c:309
#4 0x000174d8 in pty_init () at init.c:31
#5 0x00012c60 in main (argc=1, argv=0xffbef944) at krlogind.c:344
(gdb) The program is running. Exit anyway? (y or n) y
[root@localhost]/local/BuildArea/krb5/krb5-1.7/src#gdb appl/bsd/kshd
GNU gdb 5.3
Copyright 2002 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and
you are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for
details.
This GDB was configured as "sparc-sun-solaris2.8"...
(gdb) run
Starting program: /local/BuildArea/krb5/krb5-1.7/src/appl/bsd/kshd
Assertion failed: k5int_i->did_run != 0, file krb5_libinit.c, line 63
Program received signal SIGABRT, Aborted.
0xff09fe08 in _libc_kill () from /usr/lib/libc.so.1
(gdb) bt
#0 0xff09fe08 in _libc_kill () from /usr/lib/libc.so.1
#1 0xff035a2c in abort () from /usr/lib/libc.so.1
#2 0xff035cd0 in _assert () from /usr/lib/libc.so.1
#3 0xff29716c in krb5int_initialize_library () at krb5_libinit.c:63
#4 0xff2c96b4 in init_common (context=0x130854, secure=0, kdc=0) at
init_ctx.c:134
#5 0x000128f0 in main (argc=1, argv=0xffbef94c) at krshd.c:280
(gdb) The program is running. Exit anyway? (y or n) y
eightball
machines not KDCs. I went back and checked the packages that were
created for 1.6.1 and 1.6.2 and they both exhibit the same problem
with krb5kdc. However at that time, the klogind binary worked fine.
I poked at it some more and found that configuring with --disable-
thread-support, I can get working binaries for Solaris 8 at least,
working on 9 now.
Tom Yu
> I am having the same problem with Solaris 8 and 9, but not 10. The
> output is the same between 8 and 9, so I am just sending 8.
> Thanks for your help,
> Steve
A comment in k5-thread.h implies that Solaris < 10 have a broken
pthread_once() that doesn't actually do anything. I thought we had a
workaround for it.
> ________________________________________________
> Kerberos mailing list Kerb...@mit.edu
> https://mailman.mit.edu/mailman/listinfo/kerberos
Ken Raeburn
> eightball <sth...@gmail.com> writes:
>
>> I am having the same problem with Solaris 8 and 9, but not 10. The
>> output is the same between 8 and 9, so I am just sending 8.
>> Thanks for your help,
>> Steve
>
> pthread_once() that doesn't actually do anything. I thought we had a
> workaround for it.
Yes... on Solaris it ought to be using the code paths that call
krb5int_pthread_loaded in the support library. Among other things,
that function may call pthread_once a couple of times, and the
function passed (loaded_test_aux) will adjust a global variable
(flag_pthread_loaded) to indicate whether it actually got invoked.
So, some more things might help track down what's going on:
- set a breakpoint in krb5int_pthread_loaded, to verify that it's
getting called
- set a breakpoint in loaded_test_aux, to see whether it's getting
called
- examine flag_pthread_loaded after the process aborts, to see how
it's set
>> #0 0xfef9fe08 in _libc_kill () from /usr/lib/libc.so.1
>> #1 0xfef35a2c in abort () from /usr/lib/libc.so.1
>> #2 0xfef35cd0 in _assert () from /usr/lib/libc.so.1
>> #3 0xff21716c in krb5int_initialize_library () at krb5_libinit.c:63
>> #4 0xff2496b4 in init_common (context=0xffbef8d4, secure=0, kdc=1)
>> at
>> init_ctx.c:134
>> #5 0x00020370 in main (argc=2, argv=0xffbef94c) at main.c:855
That's about what I'd expect, given the assertion message text...
Ken
eightball
> Yes... on Solaris it ought to be using the code paths that call
> krb5int_pthread_loaded in the support library. Among other things,
> that function may call pthread_once a couple of times, and the
> function passed (loaded_test_aux) will adjust a global variable
> (flag_pthread_loaded) to indicate whether it actually got invoked.
>
> So, some more things might help track down what's going on:
> - set a breakpoint in krb5int_pthread_loaded, to verify that it's
> getting called
> - set a breakpoint in loaded_test_aux, to see whether it's getting
> called
> - examine flag_pthread_loaded after the process aborts, to see how
> it's set
I am not familiar with gdb. If I did it incorrectly, some help would
be appreciated:
[root@localhost]/local/BuildArea/krb5/krb5-1.7/src#gdb kdc/krb5kdc
GNU gdb 5.3
Copyright 2002 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and
you are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for
details.
This GDB was configured as "sparc-sun-solaris2.8"...
(gdb) break main
Breakpoint 1 at 0x2033c: file main.c, line 838.
(gdb) run -n
Starting program: /local/BuildArea/krb5/krb5-1.7/src/kdc/krb5kdc -n
Breakpoint 1, main (argc=2, argv=0xffbef934) at main.c:838
838 if (strrchr(argv[0], '/'))
(gdb) break krb5int_pthread_loaded
Breakpoint 2 at 0xff182024: file threads.c, line 135.
(gdb) break loaded_test_aux
Breakpoint 3 at 0xff181fe0: file threads.c, line 126.
(gdb) continue
Continuing.
Assertion failed: k5int_i->did_run != 0, file krb5_libinit.c, line 63
Program received signal SIGABRT, Aborted.
0xfef9fe08 in _libc_kill () from /usr/lib/libc.so.1
(gdb) print flag_pthread_loaded
$1 = -1
Ken Raeburn
> I am not familiar with gdb. If I did it incorrectly, some help would
> be appreciated:
No, it looks right...
> (gdb) run -n
> Starting program: /local/BuildArea/krb5/krb5-1.7/src/kdc/krb5kdc -n
>
> Breakpoint 1, main (argc=2, argv=0xffbef934) at main.c:838
> 838 if (strrchr(argv[0], '/'))
> (gdb) break krb5int_pthread_loaded
> Breakpoint 2 at 0xff182024: file threads.c, line 135.
> (gdb) break loaded_test_aux
> Breakpoint 3 at 0xff181fe0: file threads.c, line 126.
> (gdb) continue
> Continuing.
> Assertion failed: k5int_i->did_run != 0, file krb5_libinit.c, line 63
Okay, it looks like it's never even calling krb5int_pthread_loaded,
which should mean that it's always following the code path (in
selecting macro definitions) that assumes the thread support is always
linked in. This would be dependent on some configuration macros,
HAVE_PRAGMA_WEAK_REF and NO_WEAK_PTHREADS; can you see which are set
in include/autoconf.h in the build tree? The former should be defined
(based on tests of the compiler, so it may also depend on which
compiler you're using), and the latter should not (selected in the
configure script based on the OS version).
Ken
eightball
>
> Okay, it looks like it's never even calling krb5int_pthread_loaded,
> which should mean that it's always following the code path (in
> selecting macro definitions) that assumes the thread support is always
> linked in. This would be dependent on some configuration macros,
> HAVE_PRAGMA_WEAK_REF and NO_WEAK_PTHREADS; can you see which are set
> in include/autoconf.h in the build tree? The former should be defined
> (based on tests of the compiler, so it may also depend on which
> compiler you're using), and the latter should not (selected in the
> configure script based on the OS version).
>
> Ken
Both are set to 1.
[root@localhost]/local/BuildArea/krb5/krb5-1.7/src#grep
HAVE_PRAGMA_WEAK_REF include/autoconf.h
#define HAVE_PRAGMA_WEAK_REF 1
[root@localhost]/local/BuildArea/krb5/krb5-1.7/src#grep
NO_WEAK_PTHREADS include/autoconf.h
#define NO_WEAK_PTHREADS 1
I am using an old version of gcc (3.2.3)
Ken Raeburn
>> This would be dependent on some configuration macros,
>> HAVE_PRAGMA_WEAK_REF and NO_WEAK_PTHREADS; can you see which are set
>> in include/autoconf.h in the build tree? The former should be
>> defined
>> (based on tests of the compiler, so it may also depend on which
>> compiler you're using), and the latter should not (selected in the
>> configure script based on the OS version).
>>
>> Ken
>
> Both are set to 1.
Okay, that sounds like it's the problem. The configure script should
be setting the latter only for Solaris 10, unless the patterns we're
checking for are wrong:
case "${host_os}" in
[...]
solaris2.[1-9])
# On Solaris 10 with gcc 3.4.3, the autoconf archive macro
doesn't
# get the right result. XXX What about Solaris 9 and earlier?
if test "$GCC" = yes ; then
PTHREAD_CFLAGS="-D_REENTRANT -pthreads"
fi
;;
solaris*)
# On Solaris 10 with gcc 3.4.3, the autoconf archive macro
doesn't
# get the right result.
if test "$GCC" = yes ; then
PTHREAD_CFLAGS="-D_REENTRANT -pthreads"
fi
# On Solaris 10, the thread support is always available in libc.
AC_DEFINE(NO_WEAK_PTHREADS,1,[Define if references to pthread
routines should be non-weak.])
;;
Can you check the setting of the host config type? In the build tree
for Solaris 8 or 9, run a grep command like this:
$ grep cv_host config.cache
ac_cv_host=${ac_cv_host=i386-apple-darwin9.8.0}
krb5_cv_host=${krb5_cv_host=i386-apple-darwin9.8.0}
$
For Solaris 9, we'd expect to see something like "sparc-sun-
solaris2.9" in there.
Oh... uh... just to check something that should've been obvious to me
to ask before... by any chance did you:
(a) use the Solaris 10-built binaries for Solaris 8 and 9, or
(b) reuse a Solaris 10 build tree for making the Solaris 8/9 binaries,
making "clean" and maybe reconfiguring but without getting rid of the
"config.cache" file?
In general (a) is not good; backwards compatibility options will often
let you do the reverse, but sometimes software built for a newer OS
version will wind up using new features that weren't available in the
old system. In this case, a working pthread_once in libc.
If (b) happened, it's sort of a similar issue but a little more
specific to the krb5 setup -- our configure script knows that Solaris
10 has better thread support, and disables the workarounds needed for
Solaris 9. And configure scripts generated with "autoconf" have the
ability to cache results of tests; I think it's disabled by default in
modern autoconf, but our script takes a while to run so we enable it,
and maybe it needs to do better checking to ensure that the cached
values were actually associated with the current system type.
If you do reuse a krb5 build tree for a different OS, you should...
hm, actually, one or two directories may get configured or not
depending on system software available, and switching from
"configured" to "not configured" may not work properly; I'd have to
check. The simplest advice is: Use a fresh build tree for each OS
version.
Ken
Wayne Rasmussen
source files.
Ref: http://mailman.mit.edu/pipermail/kerberos/2009-October/015426.html
Is there a fix for the configure? How to get this work compile properly on
a solaris 9 sparc system?
Tom Shaw
> On Oct 19, 2009, at 16:55, eightball wrote:
>
> >> This would be dependent on some configuration macros,
> >> HAVE_PRAGMA_WEAK_REF and NO_WEAK_PTHREADS; can you see which are set
> >> in include/autoconf.h in the build tree? The former should be
> >> defined
> >> (based on tests of the compiler, so it may also depend on which
> >> compiler you're using), and the latter should not (selected in the
> >> configure script based on the OS version).
>
> >> Ken
>
> > Both are set to 1.
>
> Okay, that sounds like it's the problem. The configure script should
> be setting the latter only for Solaris 10, unless the patterns we're
> checking for are wrong:
> solaris2.[1-9])
> [...]
I hadthe same problem on Solaris 9. I just downloaded the latest
krb5-1.7-signed.tar (http://web.mit.edu/kerberos/dist/krb5/1.7/
krb5-1.7-signed.tar) and the configure script is not quite the same as
you have listed.
Instead of:
solaris2.[1-9])
the configure script has:
solaris2.1-9)
Changing the configure script to your version (with the square
brackets), and re-building fixed the problem.
Regards
Tom
--
Tom Shaw
Solid Systems Australia
Ken Raeburn
> I hadthe same problem on Solaris 9. I just downloaded the latest
> krb5-1.7-signed.tar (http://web.mit.edu/kerberos/dist/krb5/1.7/
> krb5-1.7-signed.tar) and the configure script is not quite the same as
> you have listed.
>
> Instead of:
> solaris2.[1-9])
>
> the configure script has:
> solaris2.1-9)
Ah, darned m4 quoting... fixing it in the sources now. Thanks for
spotting that. The code I had quoted was from the aclocal.m4 file
supplying macros to be run through m4 to generate the configure
script, and not the actual generated configure script itself. In most
of the macro processing, [] are quoting characters, and one level of
them (or more, depending on usage) get removed...
Ken
Leon....@thomsonreuters.com
I'm following your thread on mailman.mit.edu/pipermail/kerberos, october
19 20:46:20
You mention a part of the configure script to detect the solaris
version:
case "${host_os}" in
[...]
solaris2.[1-9])
# On Solaris 10 with gcc 3.4.3, the autoconf archive macro
doesn't
# get the right result. XXX What about Solaris 9 and earlier?
if test "$GCC" = yes ; then
PTHREAD_CFLAGS="-D_REENTRANT -pthreads"
fi
;;
solaris*)
# On Solaris 10 with gcc 3.4.3, the autoconf archive macro
doesn't
# get the right result.
if test "$GCC" = yes ; then
PTHREAD_CFLAGS="-D_REENTRANT -pthreads"
fi
# On Solaris 10, the thread support is always available in libc.
AC_DEFINE(NO_WEAK_PTHREADS,1,[Define if references to pthread
routines should be non-weak.])
;;
However the version that I just downloaded as krb5-1.7.tar.gz does not
have these square brackets around [1-9] for checking the solaris
version, i.e. it reads:
[...]
solaris2.1-9)
# On Solaris 10 with gcc 3.4.3, the autoconf archive macro
doesn't
Maybe you're refering to a more recent repository version?
Is there a version that I could download which would yield better
results on solaris 8 for compilation?
Regards
Leon
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
* * *
Leon Kemna
Senior Consultant, System Integration
Market Risk Management
Thomson Reuters
Antonio Vivaldistraat 50, Amsterdam 1083 HP, Netherlands
Desk: +31-(0)20-5045060 | Mobile: +31-(0)6-29531329
Fax: +31-(0)20-5045910 | Reception: +31-(0)20-5045045
Support, Data & Applications: 0800 - 0200 385
Support, Technical: 0800 - 0200 386
For product support, updates and training, go to thomsonreuters.com
<http://thomsonreuters.com/>
This email was sent to you by Thomson Reuters, the global news and information company.
Any views expressed in this message are those of the individual sender, except where the sender specifically states them to be the views of Thomson Reuters.
Ken Raeburn
> Maybe you're refering to a more recent repository version?
> Is there a version that I could download which would yield better
> results on solaris 8 for compilation?
Oh, and regarding Solaris 8... I'd forgotten when I sent my earlier
email, but there are additional problems if you're working with
multithreaded software. Arlene Berry reported details at http://krbdev.mit.edu/rt/Ticket/Display.html?id=6569
along with a patch, but we don't have a fix in the source tree as
yet. (Arlene's patch should work fine for Solaris 8; a patch for the
distribution probably shouldn't serialize DNS searches on platforms
where it isn't necessary.)
If your software is single-threaded (as all the Kerberos programs in
the MIT distribution are), then this shouldn't present any problems.
Ken
Ken Raeburn
Check the messages from November -- Tom Shaw pointed this out too, and
I tracked down the problem.
There's also an entry in the bug database now, including a pointer to
the fix(es) checked in. http://krbdev.mit.edu/rt/Ticket/Display.html?id=6579
With that patch applied, and the configure script regenerated with
autoconf, you ought to be able to use 1.7 with Solaris 8, as far as I
know.
Ken
Leon....@thomsonreuters.com
thanks for your reply!
Yes this seems exactly the issue; I just solaris2.1-9) to
solaris2.[1-9]) in the configure script and everything seems to work
fine.
I see the patch will be in 1.7.1 so maybe I can try to compile with that
version once available :-)
Regards
Leon
-----Original Message-----
From: Ken Raeburn [mailto:rae...@MIT.EDU]
Sent: 12 Nov 2009 19:07
To: Kemna, Leon H. (M Risk)
Cc: Kerberos mailing list
Subject: Re: Assertion failed for krb5kdc
Ken