Assertion failuers - Kerberos

This is a discussion on Assertion failuers - Kerberos ; Folks, I recently tested a change from 1.3.1 to 1.4.1 on our Solaris 2.6, 8, and 9 machines. Things worked well, except that on Solaris 2.6, several applications, including openssh and a homegrown app through this: Assertion failed: i->did_run != ...

+ Reply to Thread
Results 1 to 16 of 16

Thread: Assertion failuers

  1. Assertion failuers

    Folks,

    I recently tested a change from 1.3.1 to 1.4.1 on our Solaris 2.6, 8, and 9
    machines.

    Things worked well, except that on Solaris 2.6, several applications,
    including openssh and a homegrown app through this:

    Assertion failed: i->did_run != 0, file
    ../../../../src/lib/krb5/../../include/k5-platform.h, line 232

    And for reference, that's:

    static inline int k5_call_init_function(k5_init_t *i)
    {
    int err;
    err = k5_once(&i->once, i->fn);
    if (err)
    return err;
    assert (i->did_run != 0);
    return i->error;
    }


    Anyone have any ideas? Note that solaris 2.6 is the ONLY version that runs
    this - and we have two servers we haven't been able to upgrade yet...

    Thoughts?

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


    ________________________________________________
    Kerberos mailing list Kerberos@mit.edu
    https://mailman.mit.edu/mailman/listinfo/kerberos

    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.2.3 (GNU/Linux)

    iD8DBQFCzaKq7lkZ1Iyv898RAuIsAKCxpeKo2lbAbmGS+dy4B9 WVzVTT1gCffjg5
    +iJ0SPCo/edgDsOLdiPHzU4=
    =0+j3
    -----END PGP SIGNATURE-----


  2. Re: Assertion failuers

    On Jul 7, 2005, at 17:46, Phil Dibowitz wrote:
    > Things worked well, except that on Solaris 2.6, several applications,
    > including openssh and a homegrown app through this:
    >
    > Assertion failed: i->did_run != 0, file
    > ../../../../src/lib/krb5/../../include/k5-platform.h, line 232
    >
    > And for reference, that's:
    >
    > static inline int k5_call_init_function(k5_init_t *i)
    > {
    > int err;
    > err = k5_once(&i->once, i->fn);
    > if (err)
    > return err;
    > assert (i->did_run != 0);
    > return i->error;
    > }


    Depending on the configuration properties and options, a couple of
    things are likely to be happening here:

    * initializers are set up to run when the shared library is loaded
    because of configure options, and it's not happening, or the various
    initializers aren't running in the order expected, so one runs and
    tries to use some other interface that was supposed to have been
    initialized already but wasn't

    * initializers are running via pthread_once, but somehow you've got a
    version of pthread_once that never calls the supplied function (some OS
    vendors seem to think this is a reasonable thing to put in libc for
    when you don't link in the pthread library, but it's not really POSIX
    compliant, which would require that either the function be present and
    behave correctly, or that it not be present)

    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?

    > Anyone have any ideas? Note that solaris 2.6 is the ONLY version that
    > runs
    > this - and we have two servers we haven't been able to upgrade yet...


    We haven't got Solaris 2.6 installed anywhere any more for testing...

    Ken

    ________________________________________________
    Kerberos mailing list Kerberos@mit.edu
    https://mailman.mit.edu/mailman/listinfo/kerberos


  3. Re: Assertion failuers

    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

    But it's pretty much anything that uses 1.4.1 including homegrown software -
    but only on 2.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):

    [root@ain openssh]# ldd default/sbin/sshd
    libbsm.so.1 => /usr/lib/libbsm.so.1
    libpam.so.1 => /usr/lib/libpam.so.1
    libdl.so.1 => /usr/lib/libdl.so.1
    libresolv.so.2 => /usr/lib/libresolv.so.2
    libcrypto.so.0.9.7 =>
    /usr/lsd/openssl/default-0.9.7/lib/libcrypto.so.0.9.7
    libposix4.so.1 => /usr/lib/libposix4.so.1
    libz.so => /usr/lib/libz.so
    libsocket.so.1 => /usr/lib/libsocket.so.1
    libnsl.so.1 => /usr/lib/libnsl.so.1
    libgssapi_krb5.so.2 =>
    /usr/lsd/kerberos/5-1.4.1/lib/libgssapi_krb5.so.2
    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
    libkrb5support.so.0 =>
    /usr/lsd/kerberos/5-1.4.1/lib/libkrb5support.so.0
    libcom_err.so.3 => /usr/lsd/kerberos/5-1.4.1/lib/libcom_err.so.3
    libc.so.1 => /usr/lib/libc.so.1
    libaio.so.1 => /usr/lib/libaio.so.1
    libmp.so.2 => /usr/lib/libmp.so.2


    And it turns out that with ssh it's either kerb auth or password auth that
    will kill it, but sshkey auth works.

    [root@ain openssh]# /usr/lsd/openssh/3.9p1.new/sbin/sshd -p 1022 -ddd
    debug2: load_server_config: filename /etc/ssh/sshd_config
    debug2: load_server_config: done config len = 367
    debug2: parse_server_config: config /etc/ssh/sshd_config len 367
    debug1: sshd version OpenSSH_3.9p1
    debug1: private host key: #0 type 0 RSA1
    debug3: Not a RSA1 key file /etc/ssh/ssh_host_rsa_key.
    debug1: read PEM private key done: type RSA
    debug1: private host key: #1 type 1 RSA
    debug3: Not a RSA1 key file /etc/ssh/ssh_host_dsa_key.
    debug1: read PEM private key done: type DSA
    debug1: private host key: #2 type 2 DSA
    debug1: rexec_argv[0]='/usr/lsd/openssh/3.9p1.new/sbin/sshd'
    debug1: rexec_argv[1]='-p'
    debug1: rexec_argv[2]='1022'
    debug1: rexec_argv[3]='-ddd'
    debug2: fd 4 setting O_NONBLOCK
    debug1: Bind to port 1022 on 0.0.0.0.
    Server listening on 0.0.0.0 port 1022.
    Generating 768 bit RSA key.
    RSA key generation complete.
    debug1: fd 5 clearing O_NONBLOCK
    debug1: Server will not fork when running in debugging mode.
    debug3: send_rexec_state: entering fd = 10 config len 367
    debug3: ssh_msg_send: type 0
    debug3: send_rexec_state: done
    debug1: rexec start in 5 out 5 newsock 5 pipe -1 sock 10
    Assertion failed: i->did_run != 0, file
    ../../../../src/lib/krb5/../../include/k5-platform.h, line 232
    Abort
    [root@ain openssh]#

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


    ________________________________________________
    Kerberos mailing list Kerberos@mit.edu
    https://mailman.mit.edu/mailman/listinfo/kerberos

    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.2.3 (GNU/Linux)

    iD8DBQFCzgdk7lkZ1Iyv898RAhn6AKDUTRXxWcPtLxbGa1EPI6 m6P8RplgCg2AWv
    E8fyfCCjnNZbZytKY2NZF1U=
    =6aQE
    -----END PGP SIGNATURE-----


  4. Re: Assertion failuers

    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.

    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?

    > 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...

    And yes, going into the Kerberos code will cause it to check whether
    the initializers got run (and in most configurations, the first time,
    should actually run the initializers).

    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.

    Ken


    ________________________________________________
    Kerberos mailing list Kerberos@mit.edu
    https://mailman.mit.edu/mailman/listinfo/kerberos


  5. Re: Assertion failuers

    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@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_pthrea d_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_pthr ead_rwlock_init=no}
    [phil@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, mostof
    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@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@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


    ________________________________________________
    Kerberos mailing list Kerberos@mit.edu
    https://mailman.mit.edu/mailman/listinfo/kerberos

    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.2.3 (GNU/Linux)

    iD8DBQFCzjgS7lkZ1Iyv898RAtq5AJ9h6/prKz0JGOedLpBmw9Ny+KMr1gCgtU+Y
    5Gl7VZDI1nidirGgv2Y7mJA=
    =/fOJ
    -----END PGP SIGNATURE-----


  6. Re: Assertion failuers

    On Fri, Jul 08, 2005 at 02:40:29AM -0400, Ken Raeburn wrote:
    > 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.


    The patch didn't work - same symptoms.

    What debugging can I provide you with?

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


    ________________________________________________
    Kerberos mailing list Kerberos@mit.edu
    https://mailman.mit.edu/mailman/listinfo/kerberos

    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.2.3 (GNU/Linux)

    iD8DBQFCzu3u7lkZ1Iyv898RAs8lAKDO9V2JbOjEEknxCSZRVV 2jzq7ahgCeKEr2
    D6VMYWIbSHi5wY9LCzkDSKU=
    =ro3u
    -----END PGP SIGNATURE-----


  7. Re: Assertion failuers

    >>>>> "Phil" == Phil Dibowitz writes:

    Phil> On Fri, Jul 08, 2005 at 02:40:29AM -0400, Ken Raeburn wrote:
    >> 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.


    Phil> The patch didn't work - same symptoms.

    Phil> What debugging can I provide you with?


    Try building --disable-shared --enable-static --disable-threads

    If that works, we almost certainly are not interested in debugging
    this any more. Solaris 2.6 is old enough that we do not have
    significant resources to support it.

    ________________________________________________
    Kerberos mailing list Kerberos@mit.edu
    https://mailman.mit.edu/mailman/listinfo/kerberos


  8. Re: Assertion failuers

    On Fri, Jul 08, 2005 at 05:42:47PM -0400, Sam Hartman wrote:
    > >>>>> "Phil" == Phil Dibowitz writes:

    >
    > Phil> On Fri, Jul 08, 2005 at 02:40:29AM -0400, Ken Raeburn wrote:
    > >> 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.

    >
    > Phil> The patch didn't work - same symptoms.
    >
    > Phil> What debugging can I provide you with?
    >
    >
    > Try building --disable-shared --enable-static --disable-threads
    >
    > If that works, we almost certainly are not interested in debugging
    > this any more. Solaris 2.6 is old enough that we do not have
    > significant resources to support it.


    That does work. Thanks.

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


    ________________________________________________
    Kerberos mailing list Kerberos@mit.edu
    https://mailman.mit.edu/mailman/listinfo/kerberos

    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.2.3 (GNU/Linux)

    iD8DBQFCzxis7lkZ1Iyv898RAk3GAJ9Bqa6cyrmNQFqmDmmiB5 0YGO9zKwCfQczB
    ttC1gf6wt/mu7qgEhxa5RcU=
    =UVVr
    -----END PGP SIGNATURE-----


  9. Re: Assertion failuers

    i work with phil as well. i was wondering what are the proc/con of using
    these flags:

    --disable-shared --enable-static --disable-threads

    in solaris 2.8 or higher?
    we have an application that since we upgraded to this version of kerberos, it occasionally core dumps on solaris 2.9. the app is a 2.6 compiled and linked app and the dbx does not analyze the core properly. i was wondering the use of above flags (specially the disable threads) might have an effect this problem. we will be away from 2.6 soon though (so we do not compile and link on 2.6 so the executable be runnable on all the versions) but until then i need to resolve the problem. i appreciate your input.



    Sam Hartman wrote:

    >>>>>>"Phil" == Phil Dibowitz writes:
    >>>>>>
    >>>>>>

    >
    > Phil> On Fri, Jul 08, 2005 at 02:40:29AM -0400, Ken Raeburn wrote:
    > >> 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.

    >
    > Phil> The patch didn't work - same symptoms.
    >
    > Phil> What debugging can I provide you with?
    >
    >
    >Try building --disable-shared --enable-static --disable-threads
    >
    >If that works, we almost certainly are not interested in debugging
    >this any more. Solaris 2.6 is old enough that we do not have
    >significant resources to support it.
    >
    >________________________________________________
    >Kerberos mailing list Kerberos@mit.edu
    >https://mailman.mit.edu/mailman/listinfo/kerberos
    >
    >


    ________________________________________________
    Kerberos mailing list Kerberos@mit.edu
    https://mailman.mit.edu/mailman/listinfo/kerberos


  10. Re: Assertion failuers

    fariba wrote:

    > i work with phil as well. i was wondering what are the proc/con of using
    > these flags:
    >
    > --disable-shared --enable-static --disable-threads
    >
    > in solaris 2.8 or higher?
    > we have an application that since we upgraded to this version of
    > kerberos, it occasionally core dumps on solaris 2.9. the app is a 2.6
    > compiled and linked app and the dbx does not analyze the core properly.
    > i was wondering the use of above flags (specially the disable threads)
    > might have an effect this problem. we will be away from 2.6 soon though
    > (so we do not compile and link on 2.6 so the executable be runnable on
    > all the versions) but until then i need to resolve the problem. i
    > appreciate your input.


    --disable-shared will turn off the building of shared libraries

    --enable-static will turn on the building of static libraries

    --disable-threads will turn off support for building multi-threaded
    applications.

    In my opinion, it is best if you build your libraries and applications
    for the specific version of the OS you are using. Backward
    compatibility only goes so far.

    Jeffrey Altman

    --
    -----------------
    This e-mail account is not read on a regular basis.
    Please send private responses to jaltman at mit dot edu

  11. Re: Assertion failuers

    >>>>> "fariba" == fariba writes:

    fariba> i work with phil as well. i was wondering what are the
    fariba> proc/con of using these flags:

    fariba> --disable-shared --enable-static --disable-threads

    It turns off threads support which gets you roughly the 1.3.x
    behavior. If miltiple threads are using the library at once you can
    run into problems. It disables shared libraries and enables static
    libraries. That means that Kerberos is linked into each application
    instead of using a dynamic library.


    --Sam

    ________________________________________________
    Kerberos mailing list Kerberos@mit.edu
    https://mailman.mit.edu/mailman/listinfo/kerberos


  12. Re: Assertion failuers


    thank you. may be i should explain what o really want to know: why by
    disabling the threads our problem on 2.6 went away? why using these
    flags was suggested? is multi-threading support kind of buggy?

    Sam Hartman wrote:

    >>>>>>"fariba" == fariba writes:
    >>>>>>
    >>>>>>

    >
    > fariba> i work with phil as well. i was wondering what are the
    > fariba> proc/con of using these flags:
    >
    > fariba> --disable-shared --enable-static --disable-threads
    >
    >It turns off threads support which gets you roughly the 1.3.x
    >behavior. If miltiple threads are using the library at once you can
    >run into problems. It disables shared libraries and enables static
    >libraries. That means that Kerberos is linked into each application
    >instead of using a dynamic library.
    >
    >
    >--Sam
    >
    >
    >


    ________________________________________________
    Kerberos mailing list Kerberos@mit.edu
    https://mailman.mit.edu/mailman/listinfo/kerberos


  13. Re: Assertion failuers

    On Jul 11, 2005, at 04:59, fariba wrote:
    > thank you. may be i should explain what o really want to know: why by
    > disabling the threads our problem on 2.6 went away? why using these
    > flags was suggested? is multi-threading support kind of buggy?


    There have been problems on some systems in determining whether the
    pthread support has been linked into the program, and arranging for
    initialization functions to be run. Unfortunately, unless we commit to
    always linking in the pthread library into all Kerberos applications,
    we're stuck trying some hacks that'll depend on behavior of various
    systems, outside the standard specifications -- things like weak
    references to thread support functions.

    It may well be that either switching to static libraries *or* disabling
    the thread support is sufficient. But as a simple answer, doing both
    is more likely to just make things work for now (without fixing the
    actual bug, of course).

    Ken

    ________________________________________________
    Kerberos mailing list Kerberos@mit.edu
    https://mailman.mit.edu/mailman/listinfo/kerberos


  14. Re: Assertion failuers

    On Sun, Jul 10, 2005 at 03:53:40PM -0400, Sam Hartman wrote:
    > >>>>> "fariba" == fariba writes:

    >
    > fariba> i work with phil as well. i was wondering what are the
    > fariba> proc/con of using these flags:
    >
    > fariba> --disable-shared --enable-static --disable-threads
    >
    > It turns off threads support which gets you roughly the 1.3.x
    > behavior. If miltiple threads are using the library at once you can
    > run into problems. It disables shared libraries and enables static
    > libraries. That means that Kerberos is linked into each application
    > instead of using a dynamic library.


    BTW, I didn't disable shared libraries (we need them), but I did disable
    threads.

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


    ________________________________________________
    Kerberos mailing list Kerberos@mit.edu
    https://mailman.mit.edu/mailman/listinfo/kerberos

    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.2.3 (GNU/Linux)

    iD8DBQFC0ws27lkZ1Iyv898RAvMTAJ9eHiJ0C2wZzSKfESoLkh 1hirje/wCdH1+E
    OVfwu3zT8WpfFvoOBOUFNBo=
    =afX4
    -----END PGP SIGNATURE-----


  15. Re: Assertion failuers

    i relinked our other application(mureqd) with the new 2.6 (thread
    disabled) and released it, to see if the process functions better now.

    Phil Dibowitz wrote:

    >On Sun, Jul 10, 2005 at 03:53:40PM -0400, Sam Hartman wrote:
    >
    >
    >>>>>>>"fariba" == fariba writes:
    >>>>>>>
    >>>>>>>

    >> fariba> i work with phil as well. i was wondering what are the
    >> fariba> proc/con of using these flags:
    >>
    >> fariba> --disable-shared --enable-static --disable-threads
    >>
    >>It turns off threads support which gets you roughly the 1.3.x
    >>behavior. If miltiple threads are using the library at once you can
    >>run into problems. It disables shared libraries and enables static
    >>libraries. That means that Kerberos is linked into each application
    >>instead of using a dynamic library.
    >>
    >>

    >
    >BTW, I didn't disable shared libraries (we need them), but I did disable
    >threads.
    >
    >
    >


    ________________________________________________
    Kerberos mailing list Kerberos@mit.edu
    https://mailman.mit.edu/mailman/listinfo/kerberos


  16. Re: Assertion failuers

    seems like it worked. we have not been getting dead mureqds for a
    while(this is our application that was failing)

    fariba wrote:

    > i relinked our other application(mureqd) with the new 2.6 (thread
    > disabled) and released it, to see if the process functions better now.
    >
    > Phil Dibowitz wrote:
    >
    >> On Sun, Jul 10, 2005 at 03:53:40PM -0400, Sam Hartman wrote:
    >>
    >>
    >>>>>>>> "fariba" == fariba writes:
    >>>>>>>>
    >>>>>>>
    >>> fariba> i work with phil as well. i was wondering what are the
    >>> fariba> proc/con of using these flags:
    >>>
    >>> fariba> --disable-shared --enable-static --disable-threads
    >>>
    >>> It turns off threads support which gets you roughly the 1.3.x
    >>> behavior. If miltiple threads are using the library at once you can
    >>> run into problems. It disables shared libraries and enables static
    >>> libraries. That means that Kerberos is linked into each application
    >>> instead of using a dynamic library.
    >>>

    >>
    >>
    >> BTW, I didn't disable shared libraries (we need them), but I did disable
    >> threads.
    >>
    >>
    >>

    >
    > ________________________________________________
    > Kerberos mailing list Kerberos@mit.edu
    > https://mailman.mit.edu/mailman/listinfo/kerberos



    ________________________________________________
    Kerberos mailing list Kerberos@mit.edu
    https://mailman.mit.edu/mailman/listinfo/kerberos


+ Reply to Thread