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.
Daniel
On Apr 11, 2007, at 1:33 PM, Daniel Henninger wrote:
On Apr 11, 2007, at 1:30 PM, Quanah Gibson-Mount wrote:
--On Wednesday, April 11, 2007 1:25 PM -0400 Daniel Henninger daniel@ncsu.edu wrote:
Been a while, but I finally caught a core dump. Of course, I'm not entirely sure why there's so few useful symbols showing since I compiled it with debugging symbols and didn't strip it. =/ Anyway, the information I got from it is interesting:
(gdb) bt # 0 0x000b4694 in ?? () # 1 0x000e175c in avl_delete () # 2 0x000b4c48 in bdb_idl_cache_put () # 3 0x000b5930 in bdb_idl_fetch_key () # 4 0x000b796c in bdb_key_read () # 5 0x000b30b0 in bdb_filter_candidates () # 6 0x000b3a28 in ?? () # 7 0x000b3a28 in ?? () Backtrace stopped: previous frame identical to this frame (corrupt stack?) (gdb)
Is it possible I just have a busted version of berkeley db?! What version are you all using? (I guess it's Oracle DB now...) We are using version 4.2.52. Built with --enable-compat185.
Hi Daniel,
What does "file slapd" say? In general, "make install" will strip the symbols from slapd even if you built it with debugging etc.
Aww crap! =( /local/ldap/libexec/slapd: ELF 32-bit MSB executable, SPARC, version 1 (SYSV), dynamically linked (uses shared libs), stripped
Didn't think about that, thanks!
As for BDB 4.2.52, you must apply the patches from Oracle as well, otherwise it is known to corrupt.
Any newer ones suuggested over 4.2.52? I have no qualms at all with upgrading, just don't want to dive into a known busticated version. =)
Daniel
--Quanah
-- Quanah Gibson-Mount Senior Systems Software Developer ITS/Shared Application Services Stanford University GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html