1:26 p.m.
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
7:35 p.m.
--On Tuesday, January 22, 2008 1:26 PM -0800 Quanah Gibson-Mount
<quanah(a)zimbra.com> wrote:
In looking at a back trace of a core file, I noticed:
Just to note, this is with OpenLDAP 2.3.37, and it happens about once a
week where it causes a core dump.
--Quanah
--
Quanah Gibson-Mount
Principal Software Engineer
Zimbra, Inc
--------------------
Zimbra :: the leader in open source messaging and collaboration
12:53 a.m.
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(a)sys-net.it
---------------------------------------
10 p.m.
--On Wednesday, January 23, 2008 9:53 AM +0100 Pierangelo Masarati
<ando(a)sys-net.it> wrote:
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.
Thanks, that helped me track down what to look for. :) It's an issue with
some cyrus-sasl modifications made locally I believe.
--Quanah
--
Quanah Gibson-Mount
Principal Software Engineer
Zimbra, Inc
--------------------
Zimbra :: the leader in open source messaging and collaboration
5613
days inactive
5615
days old
3 comments
2 participants
participants (2)
-
Pierangelo Masarati -
Quanah Gibson-Mount