Full_Name: Miguel Angel Ajo Pelayo Version: 2.4.23 stable OS: Linux (Centos5) URL: Submission from: (NULL) (95.16.169.142) I detected that my (compiled from source) openldap crashes on node rename. I run gdb and detected an infinite (too big) recursion that seems to be related with the "memberof" overlay. This is the GDB / debug output: >>> dnNormalize: <cn=aaa aaavzadadfa,dc=nbee,dc=es> <<< dnNormalize: <cn=aaa aaavzadadfa,dc=nbee,dc=es> bdb_modrdn: new ndn=cn=aaa aaavzadadfa,dc=nbee,dc=es => bdb_dn2id("cn=aaa aaavzadadfa,dc=nbee,dc=es") <= bdb_dn2id: get failed: DB_NOTFOUND: No matching key/data pair found (-30988) => bdb_dn2id_delete 0x11: "cn=aaa aaavzadadf,dc=nbee,dc=es" <= bdb_dn2id_delete 0x11: 0 => bdb_dn2id_add 0x11: "cn=aaa aaavzadadfa,dc=nbee,dc=es" <= bdb_dn2id_add 0x11: 0 bdb_modify_internal: 0x00000011: cn=aaa aaavzadadfa,dc=nbee,dc=es oc_check_required entry (cn=aaa aaavzadadfa,dc=nbee,dc=es), objectClass "inetOrgPerson" oc_check_required entry (cn=aaa aaavzadadfa,dc=nbee,dc=es), objectClass "posixAccount" oc_check_allowed type "givenName" oc_check_allowed type "sn" oc_check_allowed type "gidNumber" oc_check_allowed type "uid" oc_check_allowed type "uidNumber" oc_check_allowed type "userPassword" oc_check_allowed type "loginShell" oc_check_allowed type "homeDirectory" oc_check_allowed type "objectClass" oc_check_allowed type "structuralObjectClass" oc_check_allowed type "entryUUID" oc_check_allowed type "creatorsName" oc_check_allowed type "createTimestamp" oc_check_allowed type "cn" oc_check_allowed type "entryCSN" oc_check_allowed type "modifiersName" oc_check_allowed type "modifyTimestamp" => key_change(DELETE,11) <= key_change 0 => key_change(DELETE,11) <= key_change 0 => key_change(DELETE,11) <= key_change 0 => key_change(DELETE,11) <= key_change 0 => key_change(DELETE,11) <= key_change 0 => key_change(DELETE,11) <= key_change 0 => key_change(DELETE,11) <= key_change 0 => key_change(DELETE,11) <= key_change 0 => key_change(DELETE,11) <= key_change 0 => key_change(DELETE,11) <= key_change 0 => key_change(DELETE,11) <= key_change 0 => key_change(DELETE,11) <= key_change 0 => key_change(DELETE,11) <= key_change 0 => key_change(DELETE,11) <= key_change 0 => key_change(DELETE,11) <= key_change 0 => key_change(DELETE,11) <= key_change 0 => key_change(DELETE,11) <= key_change 0 => key_change(DELETE,11) <= key_change 0 => key_change(DELETE,11) <= key_change 0 => key_change(ADD,11) <= key_change 0 => key_change(ADD,11) <= key_change 0 => key_change(ADD,11) <= key_change 0 => key_change(ADD,11) <= key_change 0 => key_change(ADD,11) <= key_change 0 => key_change(ADD,11) <= key_change 0 => key_change(ADD,11) <= key_change 0 => key_change(ADD,11) <= key_change 0 => key_change(ADD,11) <= key_change 0 => key_change(ADD,11) <= key_change 0 => key_change(ADD,11) <= key_change 0 => key_change(ADD,11) <= key_change 0 => key_change(ADD,11) <= key_change 0 => key_change(ADD,11) <= key_change 0 => key_change(ADD,11) <= key_change 0 => key_change(ADD,11) <= key_change 0 => key_change(ADD,11) <= key_change 0 => key_change(ADD,11) <= key_change 0 => key_change(ADD,11) <= key_change 0 => key_change(ADD,11) <= key_change 0 => entry_encode(0x00000011): cn=aaa aaavzadadfa,dc=nbee,dc=es <= entry_encode(0x00000011): cn=aaa aaavzadadfa,dc=nbee,dc=es bdb_modrdn: rdn modified id=00000011 dn="cn=aaa aaavzadadf,dc=nbee,dc=es" send_ldap_result: conn=1007 op=2 p=3 Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0xb79e7b90 (LWP 11613)] 0x080eaf7e in over_op_func (op=0xb79e680c, rs=0xb79e67d0, which=op_aux_chk_controls) at backover.c:713 713 db = *op->o_bd; #0 0x080eaf7e in over_op_func (op=0xb79e680c, rs=0xb79e67d0, which=op_aux_chk_controls) at backover.c:713 #1 0x080eb21c in over_aux_chk_controls (op=0xb79e680c, rs=0xb79e67d0) at backover.c:814 #2 0x0807bc38 in backend_check_restrictions (op=0xb79e680c, rs=0xb79e67d0, opdata=0x0) at backend.c:1036 #3 0x0806e1fa in fe_op_search (op=0xb79e680c, rs=0xb79e67d0) at search.c:334 #4 0x080eae42 in overlay_op_walk (op=0xb79e680c, rs=0xb79e67d0, which=op_search, oi=0x8304f40, on=0x0) at backover.c:669 #5 0x080eaff7 in over_op_func (op=0xb79e680c, rs=0xb79e67d0, which=op_search) at backover.c:721 #6 0x080eb0a6 in over_op_search (op=0xb79e680c, rs=0xb79e67d0) at backover.c:748 #7 0x0806e3a3 in fe_op_search (op=0xb79e680c, rs=0xb79e67d0) at search.c:366 [.......] A LOT of recursion... #37385 0x080eaff7 in over_op_func (op=0xb79e680c, rs=0xb79e67d0, which=op_search) at backover.c:721 #37386 0x080eb0a6 in over_op_search (op=0xb79e680c, rs=0xb79e67d0) at backover.c:748 #37387 0x0806e3a3 in fe_op_search (op=0xb79e680c, rs=0xb79e67d0) at search.c:366 #37388 0x080eae42 in overlay_op_walk (op=0xb79e680c, rs=0xb79e67d0, which=op_search, oi=0x8304f40, on=0x0) at backover.c:669 #37389 0x080eaff7 in over_op_func (op=0xb79e680c, rs=0xb79e67d0, which=op_search) at backover.c:721 #37390 0x080eb0a6 in over_op_search (op=0xb79e680c, rs=0xb79e67d0) at backover.c:748 #37391 0x08163ee4 in memberof_isGroupOrMember (op=0x8370ce0, mci=0xb6fe4450) at memberof.c:288 ---Type <return> to continue, or q <return> to quit--- #37392 0x0816723b in memberof_res_modrdn (op=0x8370ce0, rs=0xb79e7134) at memberof.c:1451 #37393 0x0807e621 in slap_response_play (op=0x8370ce0, rs=0xb79e7134) at result.c:402 #37394 0x0807e7cc in send_ldap_response (op=0x8370ce0, rs=0xb79e7134) at result.c:476 #37395 0x0807f5a2 in slap_send_ldap_result (op=0x8370ce0, rs=0xb79e7134) at result.c:750 #37396 0x080fbca9 in bdb_modrdn (op=0x8370ce0, rs=0xb79e7134) at modrdn.c:789 #37397 0x0808bbb0 in fe_op_modrdn (op=0x8370ce0, rs=0xb79e7134) at modrdn.c:314 #37398 0x080eae42 in overlay_op_walk (op=0x8370ce0, rs=0xb79e7134, which=op_modrdn, oi=0x8304f40, on=0x0) at backover.c:669 #37399 0x080eaff7 in over_op_func (op=0x8370ce0, rs=0xb79e7134, which=op_modrdn) at backover.c:721 #37400 0x080eb10c in over_op_modrdn (op=0x8370ce0, rs=0xb79e7134) at backover.c:766 #37401 0x0808b513 in do_modrdn (op=0x8370ce0, rs=0xb79e7134) at modrdn.c:186 #37402 0x0806aed0 in connection_operation (ctx=0xb79e7220, arg_v=0x8370ce0) at connection.c:1109 #37403 0x0806b410 in connection_read_thread (ctx=0xb79e7220, argv=0xe) at connection.c:1245 #37404 0x081b5055 in ldap_int_thread_pool_wrapper (xpool=0x82d9e00) at tpool.c:685 #37405 0x00adf832 in start_thread () from /lib/libpthread.so.0 #37406 0x00220e0e in clone () from /lib/libc.so.6 Any idea of why could this be happening?
changed notes
Can you provide a minimal example that triggers the problem? You should boil it down to: - the slapd.conf or the contents of the cn=config database - the LDIF needed to populate the database - the operation that causes the problem (I presume it's a modify or a write operation, so you should be able to provide it in form of LDIF and main parameters, e.g. the identity that is performing the operation). Thanks, p.
changed state Open to Feedback
Hello, Due to lack of response, this ITS will be closed. If you continue to encounter the issue with the current OpenLDAP release, please follow up with the information that was requested. Regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>
slapo-memberof need details
changed notes changed state Feedback to Closed