[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
RE: slapd crash
I believe this belongs on the openldap-software list.
Since slapd itself is a threaded app and uses threaded libraries, every other
shared library that it links with must also be built as a threaded lib. Since
you've already discovered that building the krb libraries with -D_REENTRANT
eliminates the crash, there's no further issue to discuss. Build your
libraries
correctly and you have no problem.
This OS/library dependent issue is independent of whether MIT's Kerberos
library
is thread-safe or not; you would have this crash even if the library was
thread-
safe because you didn't build it with thread support.
Some of slapd's calls to the password library are mutex-protected, some are
not.
This probably needs to be cleaned up. Of course, I would clean this up
further
by deleting the kpasswd feature entirely, for reasons already discussed on
the
-software list.
-- Howard Chu
Chief Architect, Symas Corp. Director, Highland Sun
http://www.symas.com http://highlandsun.com/hyc
Symas: Premier OpenSource Development and Support
> -----Original Message-----
> From: owner-openldap-devel@OpenLDAP.org
> [mailto:owner-openldap-devel@OpenLDAP.org]On Behalf Of Glenn Case
> Sent: Wednesday, July 03, 2002 12:44 PM
> To: openldap-devel@OpenLDAP.org
> Subject: slapd crash
>
>
> I have found a crash in slapd
> I think I have the reason for the crash
>
> The Environment
>
> Solaris 8
> openssl 2.1.2 or openssl 2.0.23
> berkly db 4.0.14
> cyrus-sasl-2.1.5 or cyrus-sasl-1.5.27
> mit krb5-1.2.5
>
> The issue appears to be that
> A) mit krb5 1.2.5 on Solaris 8 is not thread safe
>
> The reason for the crash appears to be the difference between the errno
> definition in solaris headers
> in multi threaded applications and non multithreaded applications.
>
> If I define _REENTRANT when I build the kerberos code the crash does not
> happen, but I do not believe that is the full fix as when I checked with
> the folks working on mit kerberos they stated that the kerberos code is
> not thread safe.
>
> The crash occurs when I have a userPassword attribute set to
> {KERBEROS}name@realm
> and try to do a simple authentication against that.
> (I know this is not recomended but I was just starting to do some
> testing to see what would work and what would not. )
>
> So I was wondering
> A) is the path to the kerberos code treated as if it was thread safe
> within openldap or not
> or is this a SASL Question
> B) and if someone has this environment working ? on solaris or on
> Linux
>
> If I turn off --with-kpasswd during the configure of openldap then
> I dont see the crash.
> But if I remember right that means the {KERBEROS} structure will not
> work.
>
> If this is the wrong mailing list please point me to the right one.
>
>
> Thanks
> Glenn Case
>
>
> my stack trace at the crash is
>
> t@6 (l@1) signal SEGV (no mapping at the fault address) in
> profile_node_iterator at 0xff1d1d1c
> 0xff1d1d1c: profile_node_iterator+0x00dc: ld [%l4 + 0x14],
> %l4
> (/opt/SUNWspro/bin/../WS6U2/bin/sparcv9/dbx) where
> current thread: t@6
> =>[1] profile_node_iterator(0xfcc0186c, 0x0, 0x0, 0xfcc01868, 0x1543b8,
> 0x0), at 0xff1d1d1c
> [2] profile_get_value(0x0, 0xfcc018d8, 0xfcc018d4, 0x201a50, 0x5f,
> 0x6d), at 0xff1d34e8
> [3] profile_get_integer(0x151d10, 0xff1d8940, 0xff1d894c, 0x0, 0x12c,
> 0xfcc0194c), at 0xff1d360c
> [4] init_common(0xfcc01a64, 0x0, 0x2da54, 0x15420a, 0x4d, 0x11), at
> 0xff1bba94
> [5] 0x89924(0xc24c4, 0x151d20, 0xfcc01c20, 0x3, 0x101b10, 0x1b), at
> 0x89923
> [6] lutil_passwd(0x15fed8, 0xfcc01c20, 0x0, 0x103bc8, 0x0, 0x0), at
> 0x89160
> [7] slap_passwd_check(0x1, 0x15ffb0, 0xfcc01c20, 0x2, 0x101f,
> 0xfcf4c), at 0x48300
> [8] ldbm_back_bind(0x149718, 0x1deba0, 0x201c88, 0x103800, 0xfcc01c30,
> 0x80), at 0x77864
> [9] do_bind(0x1deba0, 0x201c88, 0x77300, 0xfac00, 0xfac00, 0xfac00),
> at 0x3cce4
> [10] 0x24cd0(0x151c80, 0x105e48, 0x0, 0x1, 0x0, 0x0), at 0x24ccf
> [11] 0x8e850(0x105e40, 0x0, 0x15fe18, 0x0, 0x1, 0xfe401000), at
> 0x8e84f
>
>
>
>