[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
root_dse SASL mech duping
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