If you know how to build OpenLDAP manually, and would like to participate in testing the next set of code for the 2.4.31 release, please do so.
Generally, get the code for RE24:
Configure & build.
Execute the test suite (via make test) after it is built.
Thanks!
--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
On 04/16/12 at 01:05pm, Quanah Gibson-Mount wrote:
If you know how to build OpenLDAP manually, and would like to participate in testing the next set of code for the 2.4.31 release, please do so.
Generally, get the code for RE24:
Configure & build.
Execute the test suite (via make test) after it is built.
Thanks!
Apart from test058*, all test run without any errors.
Tested on Fedora 16 64bit: Linux myhost 3.3.1-3.fc16.x86_64 #1 SMP Wed Apr 4 18:08:51 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux
Quanah Gibson-Mount wrote:
If you know how to build OpenLDAP manually, and would like to participate in testing the next set of code for the 2.4.31 release, please do so.
I currently see two strange effects:
1. When trying to add an entry which does not conform to the schema (incomplete account/posixAccount) slapd seg faults.
2. I have hangs in the client through python-ldap after slapd died. Not sure whether that's related to OpenLDAP client libs though.
I'm currently busy. Maybe I find the time to examine it this evening.
Ciao, Michael.
Michael Ströder wrote:
Quanah Gibson-Mount wrote:
If you know how to build OpenLDAP manually, and would like to participate in testing the next set of code for the 2.4.31 release, please do so.
I currently see two strange effects:
- When trying to add an entry which does not conform to the schema
(incomplete account/posixAccount) slapd seg faults.
Need more info. I've added an entry with missing required attr (e.g. uidNumber) and get no segfault. Obviously we can't even begin to guess what's going wrong if you don't post the sample entry, minimal slapd config, etc...
- I have hangs in the client through python-ldap after slapd died. Not sure
whether that's related to OpenLDAP client libs though.
I'm currently busy. Maybe I find the time to examine it this evening.
Howard Chu wrote:
Michael Ströder wrote:
Quanah Gibson-Mount wrote:
If you know how to build OpenLDAP manually, and would like to participate in testing the next set of code for the 2.4.31 release, please do so.
I currently see two strange effects:
- When trying to add an entry which does not conform to the schema
(incomplete account/posixAccount) slapd seg faults.
Need more info. I've added an entry with missing required attr (e.g. uidNumber) and get no segfault. Obviously we can't even begin to guess what's going wrong if you don't post the sample entry, minimal slapd config, etc...
With back-mdb (did *not* test other backend) and the following lines in slapd.conf...
overlay unique unique_attributes uid uidNumber sambaSID homeDirectory
...adding this LDIF
dn: uid=testuser3,ou=posixautogen,ou=Testing,dc=stroeder,dc=de cn: Test User 3 gidNumber: 10001 homeDirectory: /home/testuser3 loginShell: /bin/false objectClass: account objectClass: posixAccount uid: testuser3 uidNumber: 10000
...causes a seg fault:
Program terminated with signal 11, Segmentation fault. #0 0x0000000000489f50 in UUIDNormalize (usage=2, syntax=0x7cbf30, mr=0x7d2160, val=0x7f702fc0fd55, normalized=0x7f700c5a3970, ctx=0xbdd0f0) at schema_init.c:2952 2952 if( val->bv_val[i] == '-' ) { (gdb) info threads 4 Thread 24095 0x00007f702edf538c in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 3 Thread 24094 0x00007f702cb4bd53 in epoll_wait () from /lib64/libc.so.6 2 Thread 24093 0x00007f702edf1cb5 in pthread_join () from /lib64/libpthread.so.0 * 1 Thread 24096 0x0000000000489f50 in UUIDNormalize (usage=2, syntax=0x7cbf30, mr=0x7d2160, val=0x7f702fc0fd55, normalized=0x7f700c5a3970, ctx=0xbdd0f0) at schema_init.c:2952 (gdb) bt full #0 0x0000000000489f50 in UUIDNormalize (usage=2, syntax=0x7cbf30, mr=0x7d2160, val=0x7f702fc0fd55, normalized=0x7f700c5a3970, ctx=0xbdd0f0) at schema_init.c:2952 nibble = 0 '\000' octet = 0 '\000' i = 0 j = 0 __PRETTY_FUNCTION__ = "UUIDNormalize" #1 0x000000000044973e in attr_normalize_one (desc=0x906850, val=0x7f702fc0fd55, nval=0x7f700c5a3970, memctx=0xbdd0f0) at attr.c:603 rc = 0 #2 0x00000000004497a2 in attr_merge_normalize_one (e=0x9f1c08, desc=0x906850, val=0x7f702fc0fd55, memctx=0xbdd0f0) at attr.c:628 nval = {bv_len = 16, bv_val = 0xe12778 "20120417182445.000003Z"} nvalp = 0x0 rc = 0 #3 0x00007f702966a80b in accesslog_response (op=0x7f7004003f30, rs=0x7f700c5a4a10) at accesslog.c:1811 pbv = 0x7f702fc0fd55 on = 0x930c80 li = 0x930e60 a = 0x0 last_attr = 0xdf7358 m = 0xe138a0 b = 0x7f70040044c0 uuid = {bv_len = 0, bv_val = 0x0} i = 8 logop = 0 lo = 0x7f70298705a0 e = 0x9f1c08 old = 0x0 e_uuid = 0x9f1bb8 timebuf = "19\000\fp\177\000\000\000\000\000\000\001\000\000\000\000AZ\fp\177\000\000\320AZ\fp\177" bv = {bv_len = 2, bv_val = 0x7f700c5a3bb0 "19"} ptr = 0x7f700c5a3d40 "\340\227\222" vals = 0x7f7004004be0 op2 = {o_hdr = 0x0, o_tag = 0, o_time = 1334687085, o_tincr = 3, o_bd = 0x0, o_req_dn = {bv_len = 0, bv_val = 0x0}, o_req_ndn = {bv_len = 0, bv_val = 0x0}, o_request = {oq_add = {rs_modlist = 0x0, rs_e = 0x0}, oq_bind = { rb_method = 0, rb_cred = {bv_len = 0, bv_val = 0x0}, rb_edn = {bv_len = 0, bv_val = 0x0}, rb_ssf = 0, rb_mech = {bv_len = 0, bv_val = 0x0}}, oq_compare = {rs_ava = 0x0}, oq_modify = {rs_mods = {rs_modlist = 0x0, rs_no_opattrs = 0 '\000'}, rs_increment = 0}, oq_modrdn = {rs_mods = {rs_modlist = 0x0, rs_no_opattrs = 0 '\000'}, rs_deleteoldrdn = 0, rs_newrdn = {bv_len = 0, bv_val = 0x0}, rs_nnewrdn = { bv_len = 0, bv_val = 0x0}, rs_newSup = 0x0, rs_nnewSup = 0x0}, oq_search = {rs_scope = 0, rs_deref = 0, rs_slimit = 0, rs_tlimit = 0, rs_limit = 0x0, rs_attrsonly = 0, rs_attrs = 0x0, rs_filter = 0x0, rs_filterstr = {bv_len = 0, bv_val = 0x0}}, oq_abandon = {rs_msgid = 0}, oq_cancel = {rs_msgid = 0}, oq_extended = {rs_reqoid = {bv_len = 0, bv_val = 0x0}, rs_flags = 0, rs_reqdata = 0x0}, oq_pwdexop = { rs_extended = {rs_reqoid = {bv_len = 0, bv_val = 0x0}, rs_flags = 0, rs_reqdata = 0x0}, rs_old = {bv_len = 0, bv_val = 0x0}, rs_new = {bv_len = 0, bv_val = 0x0}, rs_mods = 0x0, rs_modtail = 0x0}}, o_abandon = 0, o_cancel = 0, o_groups = 0x0, o_do_not_cache = 0 '\000', o_is_auth_check = 0 '\000', o_dont_replicate = 0 '\000', o_acl_priv = ACL_NONE, o_nocaching = 0 '\000', o_delete_glue_parent = 0 '\000', o_no_schema_check = 0 '\000', o_no_subordinate_glue = 0 '\000', o_ctrlflag = '\000' <repeats 31 times>, o_controls = 0x0, o_authz = { sai_method = 0, sai_mech = {bv_len = 0, bv_val = 0x0}, sai_dn = {bv_len = 0, bv_val = 0x0}, sai_ndn = { bv_len = 0, bv_val = 0x0}, sai_ssf = 0, sai_transport_ssf = 0, sai_tls_ssf = 0, sai_sasl_ssf = 0}, o_ber = 0x0, o_res_ber = 0x0, o_callback = 0x0, o_ctrls = 0x0, o_csn = {bv_len = 0, bv_val = 0x0}, o_private = 0x0, o_extra = {slh_first = 0x0}, o_next = {stqe_next = 0x0}} rs2 = {sr_type = REP_RESULT, sr_tag = 0, sr_msgid = 0, sr_err = 0, sr_matched = 0x0, sr_text = 0x0, 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} sai_method = 0, sai_mech = {bv_len = 0, bv_val = 0x0}, sai_dn = {bv_len = 0, bv_val = 0x0}, sai_ndn = { bv_len = 0, bv_val = 0x0}, sai_ssf = 0, sai_transport_ssf = 0, sai_tls_ssf = 0, sai_sasl_ssf = 0}, o_ber = 0x0, o_res_ber = 0x0, o_callback = 0x0, o_ctrls = 0x0, o_csn = {bv_len = 0, bv_val = 0x0}, o_private = 0x0, o_extra = {slh_first = 0x0}, o_next = {stqe_next = 0x0}} rs2 = {sr_type = REP_RESULT, sr_tag = 0, sr_msgid = 0, sr_err = 0, sr_matched = 0x0, sr_text = 0x0, 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} ---Type <return> to continue, or q <return> to quit--- #4 0x00000000004ce832 in over_back_response (op=0x7f7004003f30, rs=0x7f700c5a4a10) at backover.c:237 oi = 0x92a9f0 on = 0x930c80 rc = 32768 be = 0x7f700c5a4460 db = {bd_info = 0x930c80, bd_self = 0x929610, be_ctrls = "\000\001\001\001\000\001\000\000\001\000\000\001\001\000\001\000\000\000\000\001\000\001\000\000\000\000\000\000\000\000\000\000\001", be_flags = 3336, be_restrictops = 0, be_requires = 0, be_ssf_set = {sss_ssf = 0, sss_transport = 0, sss_tls = 0, sss_sasl = 0, sss_update_ssf = 0, sss_update_transport = 0, sss_update_tls = 0, sss_update_sasl = 0, sss_simple_bind = 0}, be_suffix = 0x9297b0, be_nsuffix = 0x9297e0, be_schemadn = { bv_len = 0, bv_val = 0x0}, be_schemandn = {bv_len = 0, bv_val = 0x0}, be_rootdn = {bv_len = 25, bv_val = 0x929840 "cn=root,dc=stroeder,dc=de"}, be_rootndn = {bv_len = 25, bv_val = 0x9299b0 "cn=root,dc=stroeder,dc=de"}, be_rootpw = {bv_len = 4, bv_val = 0x92be00 "test"}, be_max_deref_depth = 15, be_def_limit = {lms_t_soft = 3600, lms_t_hard = 0, lms_s_soft = -1, lms_s_hard = 0, lms_s_unchecked = -1, lms_s_pr = 0, lms_s_pr_hide = 0, lms_s_pr_total = 0}, be_limits = 0x0, be_acl = 0x931050, be_dfltaccess = ACL_READ, be_extra_anlist = 0x0, be_update_ndn = {bv_len = 0, bv_val = 0x0}, be_update_refs = 0x0, be_pending_csn_list = 0xab9610, be_pcl_mutex = {__data = {__lock = 0, __count = 0, __owner = 0, __nusers = 0, __kind = 0, __spins = 0, __list = {__prev = 0x0, __next = 0x0}}, __size = '\000' <repeats 39 times>, __align = 0}, be_syncinfo = 0x0, be_pb = 0x0, be_cf_ocs = 0x7f702a35aaa0, be_private = 0x7f70300e6010, be_next = {stqe_next = 0x933050}} #5 0x00000000004527ed in slap_response_play (op=0x7f7004003f30, rs=0x7f700c5a4a10) at result.c:507 sc_next = 0xe126a8 sc_nextp = 0x7f700c5a4440 rc = 32768 sc = 0xe12730 scp = 0xe12730 #6 0x0000000000452a12 in send_ldap_response (op=0x7f7004003f30, rs=0x7f700c5a4a10) at result.c:582 berbuf = { buffer = "\001\000\000\000\000\000\000\000 N\221", '\000' <repeats 13 times>"\260, \227\222\000\000\000\000\000\340\227\222", '\000' <repeats 21 times>, "xQ\221\000\000\000\000\000\240?Z\fp\177\000\000\270?Z\fp\177\000\000@\230\222\000\001\000\000\000&\032\202(p\177\000\000\360н\000\000\000\000\000\230\070\341\000\000\000\000\000\000\276\222\000\000\000\000\000\017\000\000\000\020\016\000\000\000\000\000\000\377\377\377\377\350@\000\004p\177\000\000\003", '\000' <repeats 15 times>, "(\233@\000\000\000\000\000H\221)0p\177\000\000\005\000\000\000\000\000\000\000\340\070\341\000\000\000\000\000 \000\000\000\000\000\000\000\360н\000\000\000\000\000\360н\000\000\000\000\000\350\070\341\000\000\000\000\000\020@Z\fp\177\000\000\002", '\000' <repeats 22 times>, ialign = 1, lalign = 1, falign = 1.40129846e-45, dalign = 4.9406564584124654e-324, palign = 0x1 <Address 0x1 out of bounds>} ber = 0x7f700c5a3f00 rc = 0 bytes = 12439792 __PRETTY_FUNCTION__ = "send_ldap_response" #7 0x00000000004538cc in slap_send_ldap_result (op=0x7f7004003f30, rs=0x7f700c5a4a10) at result.c:860 tmp = 0x0 otext = 0x7f702882737b "some attributes not unique" oref = 0x0 __PRETTY_FUNCTION__ = "slap_send_ldap_result" #8 0x00007f7028825145 in unique_search (op=0x7f7004003f30, nop=0x7f700c5a41d0, dn=0x9297e0, scope=2, rs=0x7f700c5a4a10, key=0x7f700c5a41c0) at unique.c:1054 on = 0x92b5c0 nrs = {sr_type = REP_RESULT, sr_tag = 101, sr_msgid = 2, sr_err = 0, sr_matched = 0x0, sr_text = 0x0, 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} cb = {sc_next = 0x0, sc_response = 0x7f7028824727 <count_attr_cb>, sc_cleanup = 0, sc_private = 0x7f700c5a40d0} uq = {ndn = 0x7f7004003f68, count = 2} rc = 0 #9 0x00007f70288258d0 in unique_add (op=0x7f7004003f30, rs=0x7f700c5a4a10) at unique.c:1172 len = 1 ks = 125 uri = 0x92b7e0 on = 0x92b5c0 private = 0x929b30 domains = 0x0 legacy = 0x92a5d0 domain = 0x92a5d0 nop = {o_hdr = 0x7f70040040a0, o_tag = 99, o_time = 1334687085, o_tincr = 2, o_bd = 0x929610, o_req_dn = { bv_len = 58, bv_val = 0xe125a0 "uid=testuser3,ou=posixautogen,ou=Testing,dc=stroeder,dc=de"}, o_req_ndn = { bv_len = 17, bv_val = 0x8f9dc0 "dc=stroeder,dc=de"}, o_request = {oq_add = {rs_modlist = 0x2, rs_e = 0xffffffffffffffff}, oq_bind = {rb_method = 2, rb_cred = {bv_len = 18446744073709551615, bv_val = 0x0}, rb_edn = {bv_len = 1, bv_val = 0x759dc0 "\003"}, rb_ssf = 14760168, rb_mech = {bv_len = 66, bv_val = 0xe12778 "20120417182445.000003Z"}}, oq_compare = {rs_ava = 0x2}, oq_modify = {rs_mods = { rs_modlist = 0x2, rs_no_opattrs = -1 '\377'}, rs_increment = 0}, oq_modrdn = {rs_mods = {rs_modlist = 0x2, rs_no_opattrs = -1 '\377'}, rs_deleteoldrdn = 0, rs_newrdn = {bv_len = 1, bv_val = 0x759dc0 "\003"}, rs_nnewrdn = {bv_len = 14760168, bv_val = 0x42 <Address 0x42 out of bounds>}, rs_newSup = 0xe12778, rs_nnewSup = 0x0}, oq_search = {rs_scope = 2, rs_deref = 0, rs_slimit = -1, rs_tlimit = -1, rs_limit = 0x0, rs_attrsonly = 1, rs_attrs = 0x759dc0, rs_filter = 0xe138e8, rs_filterstr = {bv_len = 66, bv_val = 0xe12778 "20120417182445.000003Z"}}, oq_abandon = {rs_msgid = 2}, oq_cancel = {rs_msgid = 2}, oq_extended = {rs_reqoid = {bv_len = 2, bv_val = 0xffffffffffffffff <Address 0xffffffffffffffff out of bounds>}, rs_flags = 0, rs_reqdata = 0x1}, oq_pwdexop = {rs_extended = {rs_reqoid = {bv_len = 2, bv_val = 0xffffffffffffffff <Address 0xffffffffffffffff out of bounds>}, rs_flags = 0, rs_reqdata = 0x1}, rs_old = {bv_len = 7708096, bv_val = 0xe138e8 "\241"}, rs_new = {bv_len = 66, bv_val = 0xe12778 "20120417182445.000003Z"}, rs_mods = 0x0, rs_modtail = 0x0}}, o_abandon = 0, o_cancel = 0, o_groups = 0x0, o_do_not_cache = 0 '\000', o_is_auth_check = 0 '\000', o_dont_replicate = 0 '\000', o_acl_priv = ACL_NONE, o_nocaching = 0 '\000', o_delete_glue_parent = 0 '\000', o_no_schema_check = 0 '\000', o_no_subordinate_glue = 0 '\000', o_ctrlflag = '\000' <repeats 31 times>, o_controls = 0x7f70040041e8, o_authz = { sai_method = 163, sai_mech = {bv_len = 8, bv_val = 0x7f70040021e0 "EXTERNAL"}, sai_dn = {bv_len = 48, bv_val = 0x7f70040021a0 "cn=michael ströder,ou=private,dc=stroeder,dc=de"}, sai_ndn = {bv_len = 25, bv_val = 0x9299b0 "cn=root,dc=stroeder,dc=de"}, sai_ssf = 71, sai_transport_ssf = 71, sai_tls_ssf = 0, sai_sasl_ssf = 0}, o_ber = 0xe05a30, o_res_ber = 0x0, o_callback = 0x7f700c5a40e0, o_ctrls = 0x0, o_csn = { bv_len = 0, bv_val = 0x0}, o_private = 0x0, o_extra = {slh_first = 0x7f700c5a4800}, o_next = {stqe_next = 0x0}} a = 0x0 key = 0xe12778 "20120417182445.000003Z" kp = 0xe127ba "" bvkey = {bv_len = 66, bv_val = 0xe12778 "20120417182445.000003Z"} rc = 32768 __PRETTY_FUNCTION__ = "unique_add" #10 0x00000000004cf6e1 in overlay_op_walk (op=0x7f7004003f30, rs=0x7f700c5a4a10, which=op_add, oi=0x92a9f0, on=0x92b5c0) at backover.c:661 func = 0x92b618 rc = 32768 #11 0x00000000004cf98e in over_op_func (op=0x7f7004003f30, rs=0x7f700c5a4a10, which=op_add) at backover.c:723 oi = 0x92a9f0 on = 0x930c80 be = 0x929610 db = {bd_info = 0x92a9f0, bd_self = 0x929610, be_ctrls = "\000\001\001\001\000\001\000\000\001\000\000\001\001\000\001\000\000\000\000\001\000\001\000\000\000\000\000\000\000\000\000\000\001", be_flags = 3336, be_restrictops = 0, be_requires = 0, be_ssf_set = {sss_ssf = 0, sss_transport = 0, sss_tls = 0, sss_sasl = 0, sss_update_ssf = 0, sss_update_transport = 0, sss_update_tls = 0, sss_update_sasl = 0, sss_simple_bind = 0}, be_suffix = 0x9297b0, be_nsuffix = 0x9297e0, be_schemadn = { bv_len = 0, bv_val = 0x0}, be_schemandn = {bv_len = 0, bv_val = 0x0}, be_rootdn = {bv_len = 25, bv_val = 0x929840 "cn=root,dc=stroeder,dc=de"}, be_rootndn = {bv_len = 25, bv_val = 0x9299b0 "cn=root,dc=stroeder,dc=de"}, be_rootpw = {bv_len = 4, bv_val = 0x92be00 "test"}, be_max_deref_depth = 15, be_def_limit = {lms_t_soft = 3600, lms_t_hard = 0, lms_s_soft = -1, lms_s_hard = 0, lms_s_unchecked = -1, lms_s_pr = 0, lms_s_pr_hide = 0, lms_s_pr_total = 0}, be_limits = 0x0, be_acl = 0x931050, be_dfltaccess = ACL_READ, be_extra_anlist = 0x0, be_update_ndn = {bv_len = 0, bv_val = 0x0}, be_update_refs = 0x0,
Michael Ströder wrote:
- I have hangs in the client through python-ldap after slapd died. Not sure
whether that's related to OpenLDAP client libs though.
This is because the Unix domain socket for the LDAPI connection is not properly closed and removed. In this case python-ldap hangs forever and the process has to be stopped with kill -9. Can I do something about it at the client side?
Ciao, Michael.
Howard Chu wrote:
Michael Ströder wrote:
Quanah Gibson-Mount wrote:
If you know how to build OpenLDAP manually, and would like to participate in testing the next set of code for the 2.4.31 release, please do so.
I currently see two strange effects:
- When trying to add an entry which does not conform to the schema
(incomplete account/posixAccount) slapd seg faults.
Need more info. I've added an entry with missing required attr (e.g. uidNumber) and get no segfault. Obviously we can't even begin to guess what's going wrong if you don't post the sample entry, minimal slapd config, etc...
With back-mdb (did *not* test other backend) and the following lines in slapd.conf...
overlay unique unique_attributes uid uidNumber sambaSID homeDirectory
...adding this LDIF
dn: uid=testuser3,ou=posixautogen,ou=Testing,dc=stroeder,dc=de cn: Test User 3 gidNumber: 10001 homeDirectory: /home/testuser3 loginShell: /bin/false objectClass: account objectClass: posixAccount uid: testuser3 uidNumber: 10000
...causes a seg fault:
Program terminated with signal 11, Segmentation fault. #0 0x0000000000489f50 in UUIDNormalize (usage=2, syntax=0x7cbf30, mr=0x7d2160, val=0x7f702fc0fd55, normalized=0x7f700c5a3970, ctx=0xbdd0f0) at schema_init.c:2952 2952 if( val->bv_val[i] == '-' ) { (gdb) info threads 4 Thread 24095 0x00007f702edf538c in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 3 Thread 24094 0x00007f702cb4bd53 in epoll_wait () from /lib64/libc.so.6 2 Thread 24093 0x00007f702edf1cb5 in pthread_join () from /lib64/libpthread.so.0
- 1 Thread 24096 0x0000000000489f50 in UUIDNormalize (usage=2,
syntax=0x7cbf30, mr=0x7d2160, val=0x7f702fc0fd55, normalized=0x7f700c5a3970, ctx=0xbdd0f0) at schema_init.c:2952 (gdb) bt full #0 0x0000000000489f50 in UUIDNormalize (usage=2, syntax=0x7cbf30, mr=0x7d2160, val=0x7f702fc0fd55, normalized=0x7f700c5a3970, ctx=0xbdd0f0) at schema_init.c:2952 nibble = 0 '\000' octet = 0 '\000' i = 0 j = 0 __PRETTY_FUNCTION__ = "UUIDNormalize" #1 0x000000000044973e in attr_normalize_one (desc=0x906850, val=0x7f702fc0fd55, nval=0x7f700c5a3970, memctx=0xbdd0f0) at attr.c:603 rc = 0 #2 0x00000000004497a2 in attr_merge_normalize_one (e=0x9f1c08, desc=0x906850, val=0x7f702fc0fd55, memctx=0xbdd0f0) at attr.c:628 nval = {bv_len = 16, bv_val = 0xe12778 "20120417182445.000003Z"} nvalp = 0x0 rc = 0 #3 0x00007f702966a80b in accesslog_response (op=0x7f7004003f30, rs=0x7f700c5a4a10) at accesslog.c:1811
Obviously an instance of slapo-accesslog(5) is involved (code related to adding reqEntryUUID to an entry). Can you be more specific about the sequence of databases and overlays and related configuration?
Thanks, p.
masarati@aero.polimi.it wrote:
Obviously an instance of slapo-accesslog(5) is involved (code related to adding reqEntryUUID to an entry). Can you be more specific about the sequence of databases and overlays and related configuration?
Disabling accesslog indeed avoids the seg fault.
Database {1}mdb suffix cn=accesslog (no overlays)
Database {2}mdb suffix dc=stroeder,dc=de Overlay {0}syncprov Overlay {1}ppolicy Overlay {2}unique Overlay {3}refint Overlay {4}memberof Overlay {5}dds Overlay {6}accesslog
overlay accesslog logdb cn=accesslog logops writes extended
Ciao, Michael.
Michael Ströder wrote:
masarati@aero.polimi.it wrote:
Obviously an instance of slapo-accesslog(5) is involved (code related to adding reqEntryUUID to an entry). Can you be more specific about the sequence of databases and overlays and related configuration?
Disabling accesslog indeed avoids the seg fault.
Database {1}mdb suffix cn=accesslog (no overlays)
Database {2}mdb suffix dc=stroeder,dc=de Overlay {0}syncprov Overlay {1}ppolicy Overlay {2}unique Overlay {3}refint Overlay {4}memberof Overlay {5}dds Overlay {6}accesslog
overlay accesslog logdb cn=accesslog logops writes extended
Maybe related to ITS#7239?
Ciao, Michael.
Michael Ströder wrote:
masarati@aero.polimi.it wrote:
Obviously an instance of slapo-accesslog(5) is involved (code related to adding reqEntryUUID to an entry). Can you be more specific about the sequence of databases and overlays and related configuration?
Disabling accesslog indeed avoids the seg fault.
Database {1}mdb suffix cn=accesslog (no overlays)
Database {2}mdb suffix dc=stroeder,dc=de Overlay {0}syncprov Overlay {1}ppolicy Overlay {2}unique Overlay {3}refint Overlay {4}memberof Overlay {5}dds Overlay {6}accesslog
overlay accesslog logdb cn=accesslog logops writes extended
I cannot reproduce with this amount of info; maybe you can cook a simple configuration and LDIF to help reproduce the issue?
Maybe related to ITS#7239?
Maybe. I've set that aside, I'd like to look into it, time permitting.
p.
overlay accesslog logdb cn=accesslog logops writes extended
The original issue should be fixed now in master.
Maybe related to ITS#7239?
Maybe the fix also addresses this issue. The problem was related to the use of an uninitialized pointer in a circumstance that could not occur when logging successful operations. I note that internal operations (related to slapo-unique(5), but also to slapo-refint(5)) get logged, or at least processed. Not sure whether this is intended or not.
p.
masarati@aero.polimi.it wrote:
overlay accesslog logdb cn=accesslog logops writes extended
The original issue should be fixed now in master.
Great.
Maybe related to ITS#7239?
Maybe the fix also addresses this issue. The problem was related to the use of an uninitialized pointer in a circumstance that could not occur when logging successful operations. I note that internal operations (related to slapo-unique(5), but also to slapo-refint(5)) get logged, or at least processed. Not sure whether this is intended or not.
Ok, will do further tests tomorrow evening.
Ciao, Michael.
masarati@aero.polimi.it wrote:
overlay accesslog logdb cn=accesslog logops writes extended
The original issue should be fixed now in master.
Your fix seems also to be in RE24. And now it works correctly. Tested with RE24 8ca44adcc0c14e45559621fb2ec47278ed5dbf77.
Maybe related to ITS#7239?
Maybe the fix also addresses this issue.
No sorry, it doesn't fix ITS#7239. I can provide a testbed configuration for this particular ITS if needed.
Ciao, Michael.
--On Wednesday, April 18, 2012 8:57 AM +0200 Michael Ströder michael@stroeder.com wrote:
Maybe the fix also addresses this issue.
No sorry, it doesn't fix ITS#7239. I can provide a testbed configuration for this particular ITS if needed.
If you could follow up to the ITS with a testbed config, that would be helpful.
--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
Quanah Gibson-Mount wrote:
--On Wednesday, April 18, 2012 8:57 AM +0200 Michael Ströder michael@stroeder.com wrote:
Maybe the fix also addresses this issue.
No sorry, it doesn't fix ITS#7239. I can provide a testbed configuration for this particular ITS if needed.
If you could follow up to the ITS with a testbed config, that would be helpful.
/bin/done
Ciao, Michael.
openldap-technical@openldap.org
-
Brandon Hume -
Howard Chu -
Jan Synacek -
Jens Vagelpohl -
masarati＠aero.polimi.it -
Michael Ströder -
Quanah Gibson-Mount