Assertion failuers

[Phil Dibowitz]

On Fri, Jul 08, 2005 at 02:40:29AM -0400, Ken Raeburn wrote:
> On Jul 8, 2005, at 00:56, Phil Dibowitz wrote:
> >On Thu, Jul 07, 2005 at 10:37:52PM -0400, Ken Raeburn wrote:
> >>Without a bit more data, it's hard to tell.  Do these applications 
> >>link
> >>against the pthread library?  Did you give any interesting options 
> >>when
> >>configuring the Kerberos code?  What did configure report when it went
> >>looking for pthread_once?
> >
> >Well, with openssh it's simply 
> >--with-kerberos5=/usr/lsd/kerberos/default
> 
> Sorry, I meant when configuring the Kerberos code.  If you didn't give 
> any special options, then how it chose to initialize the library 
> probably comes down to whether there's a stub for pthread_once in the C 
> library, and maybe which compiler and linker got used for the build.

Ohhh, sorry.

> If you still have the krb5 build tree, could you grep for 'pthread' in 
> the config.cache file at the top of the build tree?

I do have it:

[phil at metallica 5.6]$ grep pthread config.cache 
ac_cv_func_pthread_mutex_lock=${ac_cv_func_pthread_mutex_lock=yes}
ac_cv_func_pthread_mutexattr_setrobust_np=${ac_cv_func_pthread_mutexattr_setrobust_np=no}
ac_cv_func_pthread_once=${ac_cv_func_pthread_once=yes}
ac_cv_func_pthread_rwlock_init=${ac_cv_func_pthread_rwlock_init=no}
ac_cv_lib_c_pthread_mutexattr_setrobust_np=${ac_cv_lib_c_pthread_mutexattr_setrobust_np=no}
ac_cv_lib_c_pthread_rwlock_init=${ac_cv_lib_c_pthread_rwlock_init=no}
[phil at metallica 5.6]$ 

> >Here's and ldd output (note that /usr/lsd/kerberos/default is the same 
> >as
> >/usr/lsd/kerberos/5-1.4.1 in this case - it's a symlink):
> 
> Looks like no pthread library there...

While I do compile kerb seperately for each version of Solaris we run, most of
our applications are compiled on 2.6 and installed everywhere since Solaris
has full backwards compatibility, so that ssh you saw is the same build that
runs on our 8 and 9 boxes (where we don't get the kerb error), and so
obviously they're not linking to a libpthread either.

Kerb doesn't link against it either. This is from Solaris 9 (remember kerb is
seperate builds):

[root at polka sbin]# ldd krb5kdc 
        libkadm5srv.so.5 =>
/usr/lsd/kerberos/5-1.4.1/lib/libkadm5srv.so.5
        libkdb5.so.4 =>  /usr/lsd/kerberos/5-1.4.1/lib/libkdb5.so.4
        libgssrpc.so.4 =>        /usr/lsd/kerberos/5-1.4.1/lib/libgssrpc.so.4
        libgssapi_krb5.so.2 =>
/usr/lsd/kerberos/5-1.4.1/lib/libgssapi_krb5.so.2
        libdes425.so.3 =>        /usr/lsd/kerberos/5-1.4.1/lib/libdes425.so.3
        libkrb5.so.3 =>  /usr/lsd/kerberos/5-1.4.1/lib/libkrb5.so.3
        libk5crypto.so.3 =>
/usr/lsd/kerberos/5-1.4.1/lib/libk5crypto.so.3
        libcom_err.so.3 =>       /usr/lsd/kerberos/5-1.4.1/lib/libcom_err.so.3
        libkrb5support.so.0 =>
/usr/lsd/kerberos/5-1.4.1/lib/libkrb5support.so.0
        libresolv.so.2 =>        /usr/lib/libresolv.so.2
        libsocket.so.1 =>        /usr/lib/libsocket.so.1
        libnsl.so.1 =>   /usr/lib/libnsl.so.1
        libc.so.1 =>     /usr/lib/libc.so.1
        libdl.so.1 =>    /usr/lib/libdl.so.1
        libmp.so.2 =>    /usr/lib/libmp.so.2
        /usr/platform/SUNW,UltraAX-i2/lib/libc_psr.so.1


and 2.6:

[root at ain sbin]# ldd krb5kdc 
        libkadm5srv.so.5 =>
/usr/lsd/kerberos/5-1.3.1/lib/libkadm5srv.so.5
        libkdb5.so.4 =>  /usr/lsd/kerberos/5-1.3.1/lib/libkdb5.so.4
        libgssrpc.so.3 =>        /usr/lsd/kerberos/5-1.3.1/lib/libgssrpc.so.3
        libgssapi_krb5.so.2 =>
/usr/lsd/kerberos/5-1.3.1/lib/libgssapi_krb5.so.2
        libdes425.so.3 =>        /usr/lsd/kerberos/5-1.3.1/lib/libdes425.so.3
        libkrb5.so.3 =>  /usr/lsd/kerberos/5-1.3.1/lib/libkrb5.so.3
        libk5crypto.so.3 =>
/usr/lsd/kerberos/5-1.3.1/lib/libk5crypto.so.3
        libcom_err.so.3 =>       /usr/lsd/kerberos/5-1.3.1/lib/libcom_err.so.3
        libsocket.so.1 =>        /usr/lib/libsocket.so.1
        libnsl.so.1 =>   /usr/lib/libnsl.so.1
        libresolv.so.2 =>        /usr/lib/libresolv.so.2
        libc.so.1 =>     /usr/lib/libc.so.1
        libdl.so.1 =>    /usr/lib/libdl.so.1
        libmp.so.2 =>    /usr/lib/libmp.so.2

which despite being in a different order, appear identical - and fwiw,
libkrb5.so doesn't link against pthread either.

> Please try out the attached patch.  It's a bit more paranoid about 
> checking for real pthread support versus broken stubs.  If that doesn't 
> fix it, we'll need to do some debugging to figure out what's going 
> wrong.

I'm a bit confused - none of the versions link against pthreads, yet one of
the 3 doesn't work - so it makes me think that kerb didn't find pthreads, so
why would the above help?

Thanks for your help Ken. I'll give the patch a shot tomorrow morning.

-- 
Phil Dibowitz
Systems Architect and Administrator
Enterprise Infrastructure / ISD / USC
UCC 180 - 213-821-5427

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://mailman.mit.edu/pipermail/kerberos/attachments/20050708/30cd066d/attachment.bin