[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
correctly and you have no problem.

This OS/library dependent issue is independent of whether MIT's Kerberos
is thread-safe or not; you would have this crash even if the library was
safe because you didn't build it with thread support.

Some of slapd's calls to the password library are mutex-protected, some are
This probably needs to be cleaned up. Of course, I would clean this up
by deleting the kpasswd feature entirely, for reasons already discussed on
-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