--On Thursday, April 12, 2007 9:17 AM -0400 Daniel Henninger daniel@ncsu.edu wrote:
Howdy! A this point I have now updated patched BDB 4.2.52 with all 5 patches from Oracle's site, and am running a slapd with actual debugging symbols. (whee!) So here's the backtrace I got this time:
# 0 0xfee12d38 in fseek () from /usr/lib/libc.so.1 # 1 0xfe343680 in krb5_ktfileint_internal_read_entry () from /local/kerberos/lib/libkrb5.so.3 # 2 0xfe343ec8 in krb5_ktfileint_read_entry () from /local/kerberos/lib/libkrb5.so.3 # 3 0xfe342660 in krb5_ktfile_get_entry () from /local/kerberos/lib/libkrb5.so.3 # 4 0xfe35bc44 in krb5_rd_req_decrypt_tkt_part () from /local/kerberos/lib/libkrb5.so.3 # 5 0xfe35bdcc in krb5_rd_req_decoded_opt () from /local/kerberos/lib/libkrb5.so.3 # 6 0xfe35c594 in krb5_rd_req_decoded () from # /local/kerberos/lib/libkrb5.so.3 7 0xfe35bb10 in krb5_rd_req () from # /local/kerberos/lib/libkrb5.so.3 8 0xfecd81ec in # krb5_gss_accept_sec_context () from /local/kerberos/lib/libgssapi_krb5.so.2 # 9 0xfece12c4 in gss_accept_sec_context () from /local/kerberos/lib/libgssapi_krb5.so.2 # 10 0xfed02410 in gssapi_server_mech_step () from /local/lib/sasl2/libgssapiv2.so.2 # 11 0xff1d95c0 in sasl_server_step () from /local/lib/libsasl2.so.2 # 12 0xff1d92b4 in sasl_server_start () from /local/lib/libsasl2.so.2 # 13 0x00074998 in slap_sasl_bind (op=0x295e898, rs=0xd7401af0) at # sasl.c:1393 14 0x0004c4d4 in fe_op_bind (op=0x295e898, rs=0xd7401af0) at # bind.c:276 15 0x0004bddc in do_bind (op=0x295e898, rs=0xd7401af0) at # bind.c:200 16 0x00032afc in connection_operation (ctx=0x170948, # arg_v=0x295e898) at connection.c:1132 # 17 0xff33cbb4 in ldap_int_thread_pool_wrapper (xpool=0x181b08) at # tpool.c:478 18 0xfed5b124 in _thread_start () from # /usr/lib/libthread.so.1 # 19 0xfed5b124 in _thread_start () from /usr/lib/libthread.so.1 Backtrace stopped: previous frame identical to this frame (corrupt stack?)
Looks to be rather Kerberos related. We are stuck back at krb5 1.2.8 at the moment (patched to hell and back for security isms) due to a soon-to-be-gone V4 requirement that was busted in the newer Kerberos dists. That said, there's no reason I couldn't rebuild Kerberos on just that box. Are you all using krb5 w/SASL? What version of Kerberos are you running?
Alternatively, is this a known problem in openldap? I vaguely recall seeing some thread or bug report or change log entry regarding a krb5 segfault issue.
Hi Daniel,
I've always advised compiling the OpenLDAP server against Heimdal Kerberos rather than MIT Kerberos, as I've found it to be faster & to be reliable. Later versions of MIT Kerberos (1.5, 1.6) take care of the reliability issues, but are still not as fast, that I've seen. As long as you are using SASL/GSSAPI (not SASL/KERBEROSV4) then you should be just fine having OpenLDAP itself compiled against Heimdal. Stanford uses MIT Kerberos for everything else, and we've had no compatibility issues there.
--Quanah
-- Quanah Gibson-Mount Senior Systems Software Developer ITS/Shared Application Services Stanford University GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html