--e89a8fb1fbfae973ef04c1b0bad6 Content-Type: text/plain; charset=ISO-8859-1
I thought I had, but I now see that I left off "full".
(gdb) bt full #0 0x0000003f6987a31c in free () from /lib64/libc.so.6 No symbol table info available. #1 0x000000000043ca3e in ava_free (op=0x7fffe8002970, ava=0x7fffe8002e50, freeit=1) at ava.c:50 No locals. #2 0x000000000042453a in filter_free_x (op=0x7fffe8002970, f=0x7fffe8002ed0, freeme=1) at filter.c:531 p = <value optimized out> next = <value optimized out> #3 0x0000000000423127 in do_search (op=0x7fffe8002970, rs=0x7ffff640b950) at search.c:260 base = {bv_len = 10, bv_val = 0x7fffe8002707 "cn=example"} siz = 1 off = <value optimized out> i = <value optimized out> #4 0x0000000000420cfb in connection_operation (ctx=0x7ffff640bab0, arg_v=0x7fffe8002970) at connection.c:1150 rc = 80 cancel = <value optimized out> op = 0x7fffe8002970 rs = {sr_type = REP_RESULT, sr_tag = 101, sr_msgid = 1, sr_err = 0, sr_matched = 0x0, sr_text = 0x56d3ae "massaged filter parse error", sr_ref = 0x0, sr_ctrls = 0x0, sr_un = {sru_search = {r_entry = 0x0, r_attr_flags = 0, r_operational_attrs = 0x0, r_attrs = 0x0, r_nentries = 0, r_v2ref = 0x0}, sru_sasl = {r_sasldata = 0x0}, sru_extended = {r_rspoid = 0x0, r_rspdata = 0x0}}, sr_flags = 0} tag = 99 opidx = SLAP_OP_SEARCH conn = 0x7ffff6c103d0 memctx = 0x7fffe8000a80 memctx_null = 0x0 memsiz = 1048576 __PRETTY_FUNCTION__ = "connection_operation" #5 0x00000000004214d5 in connection_read_thread (ctx=0x7ffff640bab0, argv=<value optimized out>) at connection.c:1286 rc = <value optimized out> cri = {op = 0x7fffe8002970, func = 0, arg = 0x0, ctx = 0x7ffff640bab0, nullop = <value optimized out>} s = <value optimized out> #6 0x000000000050cc30 in ldap_int_thread_pool_wrapper (xpool=0x8809a0) at tpool.c:688 pool = 0x8809a0 task = 0x7ffff00008c0 work_list = <value optimized out> ctx = {ltu_id = 140737324828416, ltu_key = {{ltk_key = 0x41fa50, ltk_data = 0x7fffe8002900, ltk_free = 0x41fb20 <conn_counter_destroy>}, {ltk_key = 0x473490, ltk_data = 0x7fffe8000a80, ltk_free = 0x4734b0 <slap_sl_mem_destroy>}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0} <repeats 30 times>}} kctx = <value optimized out> keyslot = 923 hash = <value optimized out> __PRETTY_FUNCTION__ = "ldap_int_thread_pool_wrapper" #7 0x0000003f69c077f1 in start_thread () from /lib64/libpthread.so.0 No symbol table info available. #8 0x0000003f698e592d in clone () from /lib64/libc.so.6 No symbol table info available.
On Mon, Jun 4, 2012 at 7:17 PM, quanah@zimbra.com wrote:
--On Tuesday, June 05, 2012 1:50 AM +0000 gahaverkamp@lbl.gov wrote:
Full_Name: Greg Haverkamp Version: 2.4.31 OS: RHEL 6.2/OS X 10.7 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (128.3.10.46)
When a request to a massaged suffix is made of back-ldap/slapo-rwm with a malformed filter, slapd crashes on the two tested platforms (RHEL 6.2/OS
X
10.7). The last bits of the debug log and the backtrace are below:
I would suggest putting slapd under gdb and providing a backtrace.
See http://www.openldap.org/faq/data/cache/59.html
--Quanah
--
Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc.
Zimbra :: the leader in open source messaging and collaboration
--e89a8fb1fbfae973ef04c1b0bad6 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I thought I had, but I now see that I left off "full".<div><br></= div><div><div>(gdb) bt full</div><div>#0 =A00x0000003f6987a31c in free () f= rom /lib64/libc.so.6</div><div>No symbol table info available.</div><div>#1= =A00x000000000043ca3e in ava_free (op=3D0x7fffe8002970, ava=3D0x7fffe8002e= 50, freeit=3D1) at ava.c:50</div> <div>No locals.</div><div>#2 =A00x000000000042453a in filter_free_x (op=3D0= x7fffe8002970, f=3D0x7fffe8002ed0, freeme=3D1) at filter.c:531</div><div>= =A0 =A0 =A0 =A0 p =3D <value optimized out></div><div>=A0 =A0 =A0 =A0= next =3D <value optimized out></div> <div>#3 =A00x0000000000423127 in do_search (op=3D0x7fffe8002970, rs=3D0x7ff= ff640b950) at search.c:260</div><div>=A0 =A0 =A0 =A0 base =3D {bv_len =3D 1= 0, bv_val =3D 0x7fffe8002707 "cn=3Dexample"}</div><div>=A0 =A0 = =A0 =A0 siz =3D 1</div><div>=A0 =A0 =A0 =A0 off =3D <value optimized out= ></div> <div>=A0 =A0 =A0 =A0 i =3D <value optimized out></div><div>#4 =A00x00= 00000000420cfb in connection_operation (ctx=3D0x7ffff640bab0, arg_v=3D0x7ff= fe8002970) at connection.c:1150</div><div>=A0 =A0 =A0 =A0 rc =3D 80</div><d= iv>=A0 =A0 =A0 =A0 cancel =3D <value optimized out></div> <div>=A0 =A0 =A0 =A0 op =3D 0x7fffe8002970</div><div>=A0 =A0 =A0 =A0 rs =3D= {sr_type =3D REP_RESULT, sr_tag =3D 101, sr_msgid =3D 1, sr_err =3D 0, sr_= matched =3D 0x0, sr_text =3D 0x56d3ae "massaged filter parse error&quo= t;, sr_ref =3D 0x0, sr_ctrls =3D 0x0, sr_un =3D {sru_search =3D {r_entry = =3D 0x0, r_attr_flags =3D 0, r_operational_attrs =3D 0x0,=A0</div> <div>=A0 =A0 =A0 =A0 =A0 =A0 =A0 r_attrs =3D 0x0, r_nentries =3D 0, r_v2ref= =3D 0x0}, sru_sasl =3D {r_sasldata =3D 0x0}, sru_extended =3D {r_rspoid = =3D 0x0, r_rspdata =3D 0x0}}, sr_flags =3D 0}</div><div>=A0 =A0 =A0 =A0 tag= =3D 99</div><div>=A0 =A0 =A0 =A0 opidx =3D SLAP_OP_SEARCH</div> <div>=A0 =A0 =A0 =A0 conn =3D 0x7ffff6c103d0</div><div>=A0 =A0 =A0 =A0 memc= tx =3D 0x7fffe8000a80</div><div>=A0 =A0 =A0 =A0 memctx_null =3D 0x0</div><d= iv>=A0 =A0 =A0 =A0 memsiz =3D 1048576</div><div>=A0 =A0 =A0 =A0 __PRETTY_FU= NCTION__ =3D "connection_operation"</div> <div>#5 =A00x00000000004214d5 in connection_read_thread (ctx=3D0x7ffff640ba= b0, argv=3D<value optimized out>) at connection.c:1286</div><div>=A0 = =A0 =A0 =A0 rc =3D <value optimized out></div><div>=A0 =A0 =A0 =A0 cr= i =3D {op =3D 0x7fffe8002970, func =3D 0, arg =3D 0x0, ctx =3D 0x7ffff640ba= b0, nullop =3D <value optimized out>}</div> <div>=A0 =A0 =A0 =A0 s =3D <value optimized out></div><div>#6 =A00x00= 0000000050cc30 in ldap_int_thread_pool_wrapper (xpool=3D0x8809a0) at tpool.= c:688</div><div>=A0 =A0 =A0 =A0 pool =3D 0x8809a0</div><div>=A0 =A0 =A0 =A0= task =3D 0x7ffff00008c0</div> <div>=A0 =A0 =A0 =A0 work_list =3D <value optimized out></div><div>= =A0 =A0 =A0 =A0 ctx =3D {ltu_id =3D 140737324828416, ltu_key =3D {{ltk_key = =3D 0x41fa50, ltk_data =3D 0x7fffe8002900, ltk_free =3D 0x41fb20 <conn_c= ounter_destroy>}, {ltk_key =3D 0x473490, ltk_data =3D 0x7fffe8000a80, lt= k_free =3D 0x4734b0 <slap_sl_mem_destroy>}, {ltk_key =3D 0x0,=A0</div=
<div>=A0 =A0 =A0 =A0 =A0 =A0 =A0 ltk_data =3D 0x0, ltk_free =3D 0} <repe= ats 30 times>}}</div><div>=A0 =A0 =A0 =A0 kctx =3D <value optimized o= ut></div><div>=A0 =A0 =A0 =A0 keyslot =3D 923</div><div>=A0 =A0 =A0 =A0 = hash =3D <value optimized out></div><div> =A0 =A0 =A0 =A0 __PRETTY_FUNCTION__ =3D "ldap_int_thread_pool_wrapper&= quot;</div><div>#7 =A00x0000003f69c077f1 in start_thread () from /lib64/lib= pthread.so.0</div><div>No symbol table info available.</div><div>#8 =A00x00= 00003f698e592d in clone () from /lib64/libc.so.6</div> <div>No symbol table info available.</div></div><div><br></div><div><br><di= v><br><div class=3D"gmail_quote">On Mon, Jun 4, 2012 at 7:17 PM, <span dir= =3D"ltr"><<a href=3D"mailto:quanah@zimbra.com" target=3D"_blank">quanah@= zimbra.com</a>></span> wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"><div class=3D"HOEnZb"><div class=3D"h5">--On= Tuesday, June 05, 2012 1:50 AM +0000 <a href=3D"mailto:gahaverkamp@lbl.gov= ">gahaverkamp@lbl.gov</a> wrote:<br>
<br> > Full_Name: Greg Haverkamp<br> > Version: 2.4.31<br> > OS: RHEL 6.2/OS X 10.7<br> > URL: <a href=3D"ftp://ftp.openldap.org/incoming/" target=3D"_blank">ft= p://ftp.openldap.org/incoming/</a><br> > Submission from: (NULL) (128.3.10.46)<br> ><br> ><br> > When a request to a massaged suffix is made of back-ldap/slapo-rwm wit= h a<br> > malformed filter, slapd crashes on the two tested platforms (RHEL 6.2/= OS X<br> > 10.7). =A0The last bits of the debug log and the backtrace are below:<= br> <br> I would suggest putting slapd under gdb and providing a backtrace.<br> <br> See <<a href=3D"http://www.openldap.org/faq/data/cache/59.html" target= =3D"_blank">http://www.openldap.org/faq/data/cache/59.html</a>><br> <br> --Quanah<br> <br> <br> <br> --<br> <br> Quanah Gibson-Mount<br> Sr. Member of Technical Staff<br> Zimbra, Inc<br> A Division of VMware, Inc.<br> --------------------<br> Zimbra :: =A0the leader in open source messaging and collaboration<br> <br> <br> </div></div></blockquote></div><br></div></div>
--e89a8fb1fbfae973ef04c1b0bad6--
-
gahaverkamp＠lbl.gov