Quanah Gibson-Mount wrote:
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?
That string is returned by libsasl2 through a call to sasl_listmech(); the list itself looks odd, with all those repetitions, so it seems to be an issue with libsasl2. of course, the issue could be caused by something else occurring earlier in slapd.
p.
Ing. Pierangelo Masarati OpenLDAP Core Team
SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it --------------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati@sys-net.it ---------------------------------------