Assertion failuers

classic Classic list List threaded Threaded
16 messages Options
Reply | Threaded
Open this post in threaded view
|

Assertion failuers

Phil Dibowitz
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           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos

attachment0 (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Assertion failuers

Kenneth G Raeburn
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           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos
Reply | Threaded
Open this post in threaded view
|

Re: Assertion failuers

Phil Dibowitz
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           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos

attachment0 (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Assertion failuers

Kenneth G Raeburn
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           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos
Reply | Threaded
Open this post in threaded view
|

Re: 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@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@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@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           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos

attachment0 (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Assertion failuers

Phil Dibowitz
In reply to this post by Kenneth G Raeburn
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           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos

attachment0 (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Assertion failuers

hartmans
>>>>> "Phil" == Phil Dibowitz <[hidden email]> 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           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos
Reply | Threaded
Open this post in threaded view
|

Re: Assertion failuers

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

> >>>>> "Phil" == Phil Dibowitz <[hidden email]> 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           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos

attachment0 (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Assertion failuers

Fariba-2
In reply to this post by hartmans
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 <[hidden email]> 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           [hidden email]
>https://mailman.mit.edu/mailman/listinfo/kerberos
>  
>

________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos
Reply | Threaded
Open this post in threaded view
|

Re: Assertion failuers

Jeffrey Altman-3
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
________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos
Reply | Threaded
Open this post in threaded view
|

Re: Assertion failuers

hartmans
In reply to this post by Fariba-2
>>>>> "fariba" == fariba  <[hidden email]> 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           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos
Reply | Threaded
Open this post in threaded view
|

Re: Assertion failuers

Fariba-2

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  <[hidden email]> 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           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos
Reply | Threaded
Open this post in threaded view
|

Re: Assertion failuers

Kenneth G Raeburn
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           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos
Reply | Threaded
Open this post in threaded view
|

Re: Assertion failuers

Phil Dibowitz
In reply to this post by hartmans
On Sun, Jul 10, 2005 at 03:53:40PM -0400, Sam Hartman wrote:

> >>>>> "fariba" == fariba  <[hidden email]> 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           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos

attachment0 (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Assertion failuers

Fariba-2
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  <[hidden email]> 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           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos
Reply | Threaded
Open this post in threaded view
|

Re: Assertion failuers

Fariba-2
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  <[hidden email]> 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           [hidden email]
> https://mailman.mit.edu/mailman/listinfo/kerberos


________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos