openldap-bugs

openldap-bugs@openldap.org

1 participants
20967 discussions

Re: (ITS#6664) Server control forwarding in back_meta and back_ldap
by hyc＠symas.com 08 Oct '10

08 Oct '10

masarati(a)aero.polimi.it wrote: >> Full_Name: Javier Sanz >> Version: 2.4.17 >> OS: Debian Linux 5.0 >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (80.38.203.12) >> >> >> back_meta and back_ldap should forward server controls that clients use in >> their >> queries to the corresponding external LDAP servers. > > Both back-ldap and back-meta forward controls to the remote servers. > >> For example, the inhability to send controls to external servers currently >> causes that RFC2696 paged results control cannot be used, so it is >> impossible to >> retrieve more results for a query than the page size configured in the >> external >> server, which often is not a big number. > > As far as I can tell, back-ldap supports paged results correctly (just > tested with HEAD and 2.4.23 code). Back-meta does not, and likely will > never do. Please note that while all back-ldap needs to do is blindly > forward control request/response, back-meta would need to separately > handle requests server-side (i.e. when the client requests the control) > and client-side (i.e. when non LDAP-compliant remote servers return the > control while the client did not request it). In between, it would need > to return the page size requested by the client and store the (possibly > paged) response of each remote server. Not worth the effort. The > solution consists in increasing the page size returned by default by > non-LDAP compliant remote servers. > > Perhaps the problem could be split in two: > > 1) allow to configure per-target mandatory use of paged results, with a > specified page size; this means that search requests hitting a specific > target would always add the paged results control to the request, and > handle control responses accordingly. > > 2) handle server-side control response in an overlay that takes care of > storing search results and returning them as appropriate. This would > (maybe inefficiently) handle paged results regardless of the backend that > is actually handling a request. > > Even if only (1) is implemented, clients would no longer need to use pr > when talking to slapd, since back-meta would handle non-LDAP compliant > remote servers that return pr response when the control is not requested. > > I think this ITS should be closed (back-ldap and back-meta do forward > controls); maybe another ITS with a back-meta feature request to handle > non-LDAP compliant remote servers could be filed. Note that the SSSVLV overlay can handle paged results locally too, thus negating any need for back-ldap/back-meta to forward it to a remote server. Obviously for greatest generality, there needs to be a way to configure which set of controls to pass through, and which to process locally. (Much like back-ldap's option to process the WhoAmI exop...) -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#6664) Server control forwarding in back_meta and back_ldap
by masarati＠aero.polimi.it 08 Oct '10

08 Oct '10

> Full_Name: Javier Sanz > Version: 2.4.17 > OS: Debian Linux 5.0 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (80.38.203.12) > > > back_meta and back_ldap should forward server controls that clients use in > their > queries to the corresponding external LDAP servers. Both back-ldap and back-meta forward controls to the remote servers. > For example, the inhability to send controls to external servers currently > causes that RFC2696 paged results control cannot be used, so it is > impossible to > retrieve more results for a query than the page size configured in the > external > server, which often is not a big number. As far as I can tell, back-ldap supports paged results correctly (just tested with HEAD and 2.4.23 code). Back-meta does not, and likely will never do. Please note that while all back-ldap needs to do is blindly forward control request/response, back-meta would need to separately handle requests server-side (i.e. when the client requests the control) and client-side (i.e. when non LDAP-compliant remote servers return the control while the client did not request it). In between, it would need to return the page size requested by the client and store the (possibly paged) response of each remote server. Not worth the effort. The solution consists in increasing the page size returned by default by non-LDAP compliant remote servers. Perhaps the problem could be split in two: 1) allow to configure per-target mandatory use of paged results, with a specified page size; this means that search requests hitting a specific target would always add the paged results control to the request, and handle control responses accordingly. 2) handle server-side control response in an overlay that takes care of storing search results and returning them as appropriate. This would (maybe inefficiently) handle paged results regardless of the backend that is actually handling a request. Even if only (1) is implemented, clients would no longer need to use pr when talking to slapd, since back-meta would handle non-LDAP compliant remote servers that return pr response when the control is not requested. I think this ITS should be closed (back-ldap and back-meta do forward controls); maybe another ITS with a back-meta feature request to handle non-LDAP compliant remote servers could be filed. p.

1 0

Re: (ITS#6667) memberof infinite recursion on node rename
by masarati＠aero.polimi.it 08 Oct '10

08 Oct '10

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.

1 0

Re: (ITS#6632) Core dump in test030 when using back-ldap
by masarati＠aero.polimi.it 08 Oct '10

08 Oct '10

Valgrind shows more issues possibly related to this ITS when SLAP_NO_SL_MALLOC is defined. When running test047, whoami results in conn=1013 op=1 EXT oid=1.3.6.1.4.1.4203.1.11.3 conn=1013 op=1 WHOAMI ==11941== Thread 5: ==11941== Conditional jump or move depends on uninitialised value(s) ==11941== at 0x820B122: rwm_op_rollback (rwm.c:62) ==11941== by 0x820B518: rwm_op_cleanup (rwm.c:165) ==11941== by 0x809EC0F: slap_cleanup_play (result.c:436) ==11941== by 0x809F34B: send_ldap_response (result.c:621) ==11941== by 0x80A0035: slap_send_ldap_extended (result.c:802) ==11941== by 0x80C90BD: fe_extended (extended.c:237) ==11941== by 0x810E8FD: overlay_op_walk (backover.c:669) ==11941== by 0x810EAB2: over_op_func (backover.c:721) ==11941== by 0x810EC71: over_op_extended (backover.c:796) ==11941== by 0x80C8D95: do_extended (extended.c:177) ==11941== by 0x808AD29: connection_operation (connection.c:1109) ==11941== by 0x808B269: connection_read_thread (connection.c:1245) ==11941== by 0x8235884: ldap_int_thread_pool_wrapper (tpool.c:685) ==11941== by 0xDEB46A: start_thread (in /lib/libpthread-2.5.so) ==11941== by 0xD42DBD: clone (in /lib/libc-2.5.so) ==11941== ==11941== Conditional jump or move depends on uninitialised value(s) ==11941== at 0x820B13A: rwm_op_rollback (rwm.c:65) ==11941== by 0x820B518: rwm_op_cleanup (rwm.c:165) ==11941== by 0x809EC0F: slap_cleanup_play (result.c:436) ==11941== by 0x809F34B: send_ldap_response (result.c:621) ==11941== by 0x80A0035: slap_send_ldap_extended (result.c:802) ==11941== by 0x80C90BD: fe_extended (extended.c:237) ==11941== by 0x810E8FD: overlay_op_walk (backover.c:669) ==11941== by 0x810EAB2: over_op_func (backover.c:721) ==11941== by 0x810EC71: over_op_extended (backover.c:796) ==11941== by 0x80C8D95: do_extended (extended.c:177) ==11941== by 0x808AD29: connection_operation (connection.c:1109) ==11941== by 0x808B269: connection_read_thread (connection.c:1245) ==11941== by 0x8235884: ldap_int_thread_pool_wrapper (tpool.c:685) ==11941== by 0xDEB46A: start_thread (in /lib/libpthread-2.5.so) ==11941== by 0xD42DBD: clone (in /lib/libc-2.5.so) conn=1013 op=1 RESULT oid= err=0 text= Possibly, although not directly, related leaks: ==11941== ==11941== 244 bytes in 4 blocks are definitely lost in loss record 10 of 11 ==11941== at 0x40053C0: malloc (vg_replace_malloc.c:149) ==11941== by 0x826BB67: ber_memalloc_x (memory.c:226) ==11941== by 0x80F5229: slap_sl_malloc (sl_malloc.c:285) ==11941== by 0x826BB82: ber_memalloc_x (memory.c:229) ==11941== by 0x824C16E: ldap_dn2bv_x (getdn.c:3015) ==11941== by 0x80A53E2: dnPrettyNormal (dn.c:745) ==11941== by 0x820D4DC: rwm_exop_passwd (rwm.c:1048) ==11941== by 0x820D7C5: rwm_extended (rwm.c:1116) ==11941== by 0x810E87D: overlay_op_walk (backover.c:659) ==11941== by 0x810EAB2: over_op_func (backover.c:721) ==11941== by 0x810EC71: over_op_extended (backover.c:796) ==11941== by 0x80C8D95: do_extended (extended.c:177) ==11941== by 0x808AD29: connection_operation (connection.c:1109) ==11941== by 0x808B269: connection_read_thread (connection.c:1245) ==11941== by 0x8235884: ldap_int_thread_pool_wrapper (tpool.c:685) ==11941== by 0xDEB46A: start_thread (in /lib/libpthread-2.5.so) ==11941== by 0xD42DBD: clone (in /lib/libc-2.5.so) Will look at this ASAP. p.

1 0

Re: (ITS#6666) Feature Request: Triggers implementation
by hyc＠symas.com 07 Oct '10

07 Oct '10

Hallvard B Furuseth wrote: > Maybe an overlay version of back-sock, with an overlay option > which says whether or not to wait for responses from the socket? Sure. Someone could easily start with e.g. chain.c or pbind.c and write an overlay wrapper for back-sock. Patches welcome. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#6666) Feature Request: Triggers implementation
by h.b.furuseth＠usit.uio.no 07 Oct '10

07 Oct '10

Maybe an overlay version of back-sock, with an overlay option which says whether or not to wait for responses from the socket?

1 0

(ITS#6667) memberof infinite recursion on node rename
by miguelangel＠nbee.es 07 Oct '10

07 Oct '10

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?

1 0

Re: (ITS#6666) Feature Request: Triggers implementation
by nick＠eurobjects.com 07 Oct '10

07 Oct '10

Sorry, I' m not a developer. I'm trying to find a solution from an administrator's point of view. How about doing something like: on log attr <attrname> notify <[ip]:[port]> which would send a "message" with the attr name, the old and the new value of the attribute to [ip]:[port]. Then, someone can set up a net listening process like netcat (nc) to read data and do whatever. Nick On 7/10/2010 5:32 πμ, Howard Chu wrote: > > Spawning processes is not thread safe. The solution you propose will > never be implemented. Alternative suggestions are welcome. >

1 0

Re: (ITS#6666) Feature Request: Triggers implementation
by hyc＠symas.com 06 Oct '10

06 Oct '10

nick(a)eurobjects.com wrote: > Full_Name: Nick Milas > Version: 2.3.43 > OS: CentOS 5.5 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (94.65.0.240) > > > Triggers in openldap is a much-desired feature. As mentioned in various places, > openldap community suggests using the accesslog overlay to log changes and then > use another process to listen to changes (e.g. back-perl) or back-sock (I saw > the example in the source tree), feasibly back-shell or even write one's own > overlay. The problem is that all those methods require low-level programming > (not to mention various incompatibilities with system components), which makes > them unusable by administrators, that is by those who mainly install and run > openldap and directories. As a result, I would suggest to slightly enhance > future versions by offering minimal trigger support over the accesslog overlay. > > > So I would suggest to support in slapd.conf a statement like: > "on log attr<attribute name> call<bash script>" (with obvious meaning). > > I consider this would allow the openldap average administrator to use particular > attributes as triggers to start scripts which in turn offer the advantage of > full access to script programming, which does not require low-level > programming. > > Spawning processes is not thread safe. The solution you propose will never be implemented. Alternative suggestions are welcome. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

memberof infinite recursion on node rename
by Miguel Angel 06 Oct '10

06 Oct '10

Hi there, I think I found a bug. 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. I'm not familiar with openldap sources, so I decided to post it here, and then try to help fixing it with your advice: 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? Thanks in advance, Miguel Angel Ajo Pelayo http://www.nbee.es +34 636 52 25 69 skype: ajoajoajo

2 1

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs