In looking at a back trace of a core file, I noticed:
(gdb) thread 7 [Switching to thread 7 (core thread 6)] #0 0x90003ba8 in szone_malloc () (gdb) bt #0 0x90003ba8 in szone_malloc () #1 0x28302c31 in ?? () #2 0x90003a00 in szone_malloc () #3 0x00105d78 in ber_memalloc_x (s=33554488, ctx=0x28302c31) at memory.c:226 #4 0x001064bc in ber_strdup_x (s=0x23d536e0 "OTP,OTP,OTPOTP,OTP,OTP,GSSAPI,GSSAPI,GSSAPI,DIGEST-MD5,DIGEST-MD5,DIGEST-MD5,CRAM-MD5,CRAM-MD5,CRAM-MD5,GSSAPI,GSSAPI,GSSAPI,DIGEST-MD5,DIGEST-MD5,DIGEST-MD5,CRAM-MD5,CRAM-MD5,CRAM-MD5", ctx=0x0) at memory.c:642 #5 0x000e3ff0 in ldap_str2charray (str_in=0x2000038 "����", brkstr=0x19d9a8 ",") at charray.c:188 #6 0x0005af4c in slap_sasl_mechs (conn=0x0) at sasl.c:1277 #7 0x00059264 in root_dse_info (conn=0x1aadeca0, entry=0xf18058c8, text=0x3e8) at root_dse.c:197 #8 0x00018d54 in fe_op_search (op=0x1b28ca0, rs=0xf1805bc4) at search.c:265 #9 0x00018bf8 in do_search (op=0x1b28ca0, rs=0xf1805bc4) at search.c:217 #10 0x00016cac in connection_operation (ctx=0x235778, arg_v=0x1b28ca0) at connection.c:1133 #11 0x000eaa1c in ldap_int_thread_pool_wrapper (xpool=0x190c420) at tpool.c:478 #12 0x9002bd08 in _pthread_body ()
Short of the duping of the SASL mechanisms (which seems somewhat silly for root_dse), I notice how the generated string seems to be incorrect, i.e., notice how it has "OTPOTP" with a missing comma. Also in #5, there seems to be some issue with a corrupted string getting introduced?
There is one other thread in this same function stack:
[Switching to thread 4 (core thread 3)] #0 0xffff85d8 in ___spin_lock_relinquish () at /System/Library/Frameworks/System.framework/PrivateHeaders/ppc/cpu_capabilities.h:186 186 in /System/Library/Frameworks/System.framework/PrivateHeaders/ppc/cpu_capabilities.h (gdb) bt #0 0xffff85d8 in ___spin_lock_relinquish () at /System/Library/Frameworks/System.framework/PrivateHeaders/ppc/cpu_capabilities.h:186 #1 0x90003a00 in szone_malloc () #2 0x90003600 in malloc () #3 0x00105d78 in ber_memalloc_x (s=0, ctx=0xffffffc3) at memory.c:226 #4 0x001064bc in ber_strdup_x (s=0x23d536e0 "OTP,OTP,OTPOTP,OTP,OTP,GSSAPI,GSSAPI,GSSAPI,DIGEST-MD5,DIGEST-MD5,DIGEST-MD5,CRAM-MD5,CRAM-MD5,CRAM-MD5,GSSAPI,GSSAPI,GSSAPI,DIGEST-MD5,DIGEST-MD5,DIGEST-MD5,CRAM-MD5,CRAM-MD5,CRAM-MD5", ctx=0x0) at memory.c:642 #5 0x000e3ff0 in ldap_str2charray (str_in=0x0, brkstr=0x19d9a8 ",") at charray.c:188 #6 0x0005af4c in slap_sasl_mechs (conn=0xa0001fac) at sasl.c:1277 #7 0x00059264 in root_dse_info (conn=0x1aadeca0, entry=0xf0c028c8, text=0x1) at root_dse.c:197 #8 0x00018d54 in fe_op_search (op=0x1bdf380, rs=0xf0c02bc4) at search.c:265 #9 0x00018bf8 in do_search (op=0x1bdf380, rs=0xf0c02bc4) at search.c:217 #10 0x00016cac in connection_operation (ctx=0x235778, arg_v=0x1bdf380) at connection.c:1133 #11 0x000eaa1c in ldap_int_thread_pool_wrapper (xpool=0x190c420) at tpool.c:478 #12 0x9002bd08 in _pthread_body ()
that exhibits the same issue of the SALS mech being OTPOTP. It seems to have a relatively normal string however in #5. Any ideas?
--Quanah
--
Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration