- openldap-bugs - openldap.org

(ITS#7188) slapschema.8 manpage formatting problems
by peb＠mppmu.mpg.de 01 Mar '12

01 Mar '12

Full_Name: Peter Breitenlohner Version: 2.4.30 OS: Linux.GNU URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (134.107.24.63) The slapschema.8 manpage exhibits some formatting problems (already present in 2.4.23 and maybe earlier): In line 30 a font change '\fR' is misspelled as '\FR' Line 56 ought to end after the word 'slapschema'; the rest should be on a separate line.

1 0

(ITS#7182) back-ldap monitoring improvements
by ondrej.kuznik＠acision.com 28 Feb '12

28 Feb '12

Full_Name: Ondrej Kuznik Version: HEAD OS: Linux URL: ftp://ftp.openldap.org/incoming/Ondrej-Kuznik-20120228-back-ldap-monitoring… Submission from: (NULL) (62.168.56.1) I have prepared some patches to back-ldap (and one to back-monitor) that expose operation and connection monitoring information from a running back-ldap database and I would like to see this or similar functionality included in the OpenLDAP codebase. The url above contains a patchset against HEAD for review. The following things are yet to be resolved: - there is no monitoring of completed operations yet, only operations initiated against the remote database(s). - the binds performed by the ldap_back_default_rebind function are not counted - slapo-chain has not been tested yet - test suite integration: back-ldap looks excluded from the test suite - better connection handling (connections should have stable identifiers) The obligatory license clause follows: The attached file is derived from OpenLDAP Software. All of the modifications to OpenLDAP Software represented in the following patch(es) were developed by Acision. Acision has not assigned rights and/or interest in this work to any party. I, Ondrej Kuznik am authorized by Acision, my employer, to release this work under the following terms. The attached modifications to OpenLDAP Software are subject to the following notice: Copyright 2012 Acision Redistribution and use in source and binary forms, with or without modification, are permitted only as authorized by the OpenLDAP Public License.

1 0

RE: (ITS#7102) slapd segfaults on slapo-dds refresh with syncprov enabled
by Petteri.Stenius＠ubisecure.com 27 Feb '12

27 Feb '12

Hello, I run into this same issue. However the segfault only happens if the dds overlay is defined before the syncprov overlay in slapd.conf. Br, Petteri Stenius -----Original Message----- From: openldap-bugs-bounces(a)OpenLDAP.org [mailto:openldap-bugs-bounces@OpenLDAP.org] On Behalf Of dieter(a)dkluenter.de Sent: 30. marraskuuta 2011 12:12 To: openldap-its(a)openldap.org Subject: (ITS#7102) slapd segfaults on slapo-dds refresh with syncprov enabled Full_Name: Dieter Kluenter Version: OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (141.38.5.243) slapd crashes with segmentation fault on a slapo-dds refresh operation, if syncprov is enabled and configured (gdb) bt #0 0x00000000004dd429 in slap_get_commit_csn (op=0x7f01d8013530, maxcsn=0x7f01e6a346d0, foundit=0x7f01e6a346cc) at ctxcsn.c:59 #1 0x00007f01f0d0a401 in syncprov_op_response (op=0x7f01d8013530, rs=0x7f01e6a34a30) at syncprov.c:1793 #2 0x000000000045cbff in slap_response_play (op=0x7f01d8013530, rs=0x7f01e6a34a30) at result.c:505 #3 0x000000000045ce24 in send_ldap_response (op=0x7f01d8013530, rs=0x7f01e6a34a30) at result.c:580 #4 0x000000000045e292 in slap_send_ldap_extended (op=0x7f01d8013530, rs=0x7f01e6a34a30) at result.c:915 #5 0x000000000048aedb in fe_extended (op=0x7f01d8013530, rs=0x7f01e6a34a30) at extended.c:237 #6 0x000000000048ab57 in do_extended (op=0x7f01d8013530, rs=0x7f01e6a34a30) at extended.c:177 #7 0x0000000000446a15 in connection_operation (ctx=0x7f01e6a34b60, arg_v=0x7f01d8013530) at connection.c:1138 #8 0x0000000000446fb3 in connection_read_thread (ctx=0x7f01e6a34b60, argv=0x10) at connection.c:1274 #9 0x00007f01f5929fc0 in ldap_int_thread_pool_wrapper (xpool=0x91d540) at tpool.c:685 #10 0x00007f01f48f0a3f in start_thread (arg=0x7f01e6a35700) at pthread_create.c:297 #11 0x00007f01f3c1166d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:112 #12 0x0000000000000000 in ?? () (gdb) frame 0 #0 0x00000000004dd429 in slap_get_commit_csn (op=0x7f01d8013530, maxcsn=0x7f01e6a346d0, foundit=0x7f01e6a346cc) at ctxcsn.c:59 59 LDAP_TAILQ_FOREACH( csne, be->be_pending_csn_list, ce_csn_link ) { (gdb) frame 1 #1 0x00007f01f0d0a401 in syncprov_op_response (op=0x7f01d8013530, rs=0x7f01e6a34a30) at syncprov.c:1793 1793 slap_get_commit_csn( op, &maxcsn, &foundit ); (gdb) frame 2 #2 0x000000000045cbff in slap_response_play (op=0x7f01d8013530, rs=0x7f01e6a34a30) at result.c:505 505 rc = op->o_callback->sc_response( op, rs ); (gdb) frame 3 #3 0x000000000045ce24 in send_ldap_response (op=0x7f01d8013530, rs=0x7f01e6a34a30) at result.c:580 580 rc = slap_response_play( op, rs ); (gdb) -Dieter

1 0

Re: (ITS#7181) off by 2 error in --ldif-wrap
by hyc＠symas.com 25 Feb '12

25 Feb '12

Hallvard B Furuseth wrote: > On Sat, 25 Feb 2012 00:19:11 GMT, hyc(a)symas.com wrote: >> h.b.furuseth(a)usit.uio.no wrote: >>> The client option --ldif-wrap=N outputs lines of N+2 columns. >>> E.g. 'ldapsearch -o ldif-wrap=20 ...' gives 22-column output. >> >> Not a bug. See libldap/ldif.c:490. > > That's old an internal matter, exposed as default wrap width 78 > instead of rfc2849's max 76. > > This ITS is about the new --ldif-wrap option. The tools can just > subtract 2 from the input value and otherwise keep the current code. But then the tools will be wrong when we fix the library. > (I do think we should throw away the old bug-compat code and > fix the default 78 to 76, but not in RE24. And I note the bug- > compat comment claims it's off by 1 while it's actually 2:) Sure, I'd like to throw that all out too. But in the meantime, I'd rather not have the tools' functionality change twice over the same issue. (I.e., fix the tools now, then fix the libraries later and have to re-fix the tools.) -- -- 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#7181) off by 2 error in --ldif-wrap
by h.b.furuseth＠usit.uio.no 24 Feb '12

24 Feb '12

On Sat, 25 Feb 2012 00:19:11 GMT, hyc(a)symas.com wrote: > h.b.furuseth(a)usit.uio.no wrote: >> The client option --ldif-wrap=N outputs lines of N+2 columns. >> E.g. 'ldapsearch -o ldif-wrap=20 ...' gives 22-column output. > > Not a bug. See libldap/ldif.c:490. That's old an internal matter, exposed as default wrap width 78 instead of rfc2849's max 76. This ITS is about the new --ldif-wrap option. The tools can just subtract 2 from the input value and otherwise keep the current code. (I do think we should throw away the old bug-compat code and fix the default 78 to 76, but not in RE24. And I note the bug- compat comment claims it's off by 1 while it's actually 2:) -- Hallvard

1 0

Re: (ITS#7181) off by 2 error in --ldif-wrap
by hyc＠symas.com 24 Feb '12

24 Feb '12

h.b.furuseth(a)usit.uio.no wrote: > Full_Name: Hallvard B Furuseth > Version: 2.4.29 > OS: Linux x86_64 > URL: > Submission from: (NULL) (195.1.106.125) > Submitted by: hallvard > > > The client option --ldif-wrap=N outputs lines of N+2 columns. > E.g. 'ldapsearch -o ldif-wrap=20 ...' gives 22-column output. Not a bug. See libldap/ldif.c:490. -- -- 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#7180) libmdb assertion error on slapadd
by quanah＠zimbra.com 24 Feb '12

24 Feb '12

--On Thursday, February 23, 2012 5:42 PM +0000 quanah(a)OpenLDAP.org wrote: >#################### 100.00% eta none elapsed none fast! > slapadd: ../../../libraries/libmdb/mdb.c:3827: mdb_cursor_get: Assertion > `mc' failed. > Aborted This is specifically triggered the flags used with slapadd: /opt/zimbra/openldap/sbin/slapadd -q -w -b '' -F /opt/zimbra/data/ldap/config -cv -l /tmp/ldap.bak Specifically the "-w" flag is what triggers it. No error occurs without -w. Thread 1 (Thread 0x7ffff7fef700 (LWP 25466)): #0 0x00007ffff6372a75 in raise () from /lib/libc.so.6 No symbol table info available. #1 0x00007ffff63765c0 in abort () from /lib/libc.so.6 No symbol table info available. #2 0x00007ffff636b941 in __assert_fail () from /lib/libc.so.6 No symbol table info available. #3 0x00007ffff38432d0 in mdb_cursor_get (mc=0x0, key=0x7ffff3a53eb0, data=0x7ffff3a53ec0, op=MDB_SET) at ../../../libraries/libmdb/mdb.c:3827 rc = 1301783142 exact = 0 __PRETTY_FUNCTION__ = "mdb_cursor_get" #4 0x00007ffff381c4db in mdb_tool_entry_get_int (be=0x8ff470, id=0, ep=0x7fffffffe568) at tools.c:323 op = {o_hdr = 0x0, o_tag = 0, o_time = 0, o_tincr = 0, 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}} ohdr = {oh_opid = 0, oh_connid = 0, oh_conn = 0x0, oh_msgid = 0, oh_protocol = 0, oh_tid = 0, oh_threadctx = 0x0, oh_tmpmemctx = 0x0, oh_tmpmfuncs = 0x0, oh_counters = 0x0, oh_log_prefix = '\000' <repeats 255 times>} e = 0x0 dn = {bv_len = 0, bv_val = 0x0} ndn = {bv_len = 0, bv_val = 0x0} rc = 32767 __PRETTY_FUNCTION__ = "mdb_tool_entry_get_int" #5 0x00007ffff381c72d in mdb_tool_entry_get (be=0x8ff470, id=0) at tools.c:373 e = 0x0 #6 0x00000000004db69a in slap_tool_update_ctxcsn (progname=0x51a020 "slapadd", sid=18446744073709551615, bvtext=0x7fffffffe6c0) at slapcommon.c:1004 ctxdn = {bv_len = 0, bv_val = 0x8d1c50 ""} ctxcsn_id = 0 ctxcsn_e = 0x75ff68 rc = 0 __PRETTY_FUNCTION__ = "slap_tool_update_ctxcsn" #7 0x00000000004d8ecb in slapadd (argc=10, argv=0x7fffffffea18) at slapadd.c:472 textbuf = '\000' <repeats 255 times> textlen = 256 erec = {e = 0x7ebf68, lineno = 2857, nextline = 2857} bvtext = {bv_len = 256, bv_val = 0x7fffffffe700 ""} thr = 0 id = 73 ldifrc = 0 rc = 0 stat_buf = {st_dev = 64256, st_ino = 1441881, st_nlink = 1, st_mode = 33184, st_uid = 1001, st_gid = 1001, __pad0 = 0, st_rdev = 0, st_size = 115070, st_blksize = 4096, st_blocks = 232, st_atim = {tv_sec = 1330122358, tv_nsec = 391982437}, st_mtim = {tv_sec = 1330122344, tv_nsec = 272000000}, st_ctim = {tv_sec = 1330122346, tv_nsec = 832002048}, __unused = {0, 0, 0}} #8 0x0000000000415910 in main (argc=10, argv=0x7fffffffea18) at main.c:410 i = 0 no_detach = 0 rc = 1 urls = 0x0 username = 0x0 groupname = 0x0 sandbox = 0x0 syslogUser = 160 pid = 0 waitfds = {3817984, 0} g_argc = 10 g_argv = 0x7fffffffea18 configfile = 0x0 configdir = 0x0 serverName = 0x7fffffffec9d "slapadd" serverMode = 1 scp = 0x0 scp_entry = 0x0 debug_unknowns = 0x0 syslog_unknowns = 0x0 serverNamePrefix = 0x4f95e8 "" l = 140737488349422 slapd_pid_file_unlink = 0 slapd_args_file_unlink = 0 firstopt = 1 __PRETTY_FUNCTION__ = "main" (gdb) -- Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#7181) off by 2 error in --ldif-wrap
by h.b.furuseth＠usit.uio.no 23 Feb '12

23 Feb '12

Full_Name: Hallvard B Furuseth Version: 2.4.29 OS: Linux x86_64 URL: Submission from: (NULL) (195.1.106.125) Submitted by: hallvard The client option --ldif-wrap=N outputs lines of N+2 columns. E.g. 'ldapsearch -o ldif-wrap=20 ...' gives 22-column output.

1 0

Re: (ITS#7177) [PATCH] various manpage fixes
by hyc＠symas.com 23 Feb '12

23 Feb '12

h.b.furuseth(a)usit.uio.no wrote: > On Thu, 23 Feb 2012 20:31:09 GMT, hyc(a)symas.com wrote: >> It seems unnecessary to document ldif-wrap in all of the commands, >> since only ldapsearch actually produces LDIF output. > > No, controls can also request LDIF output. E.g. > ldapmodify -e preread -o ldif-wrap=20 > wraps after column... 22?? New ITS coming up. > OK, in that case I don't see any reason to tweak that part of the patch. -- -- 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#7177) [PATCH] various manpage fixes
by h.b.furuseth＠usit.uio.no 23 Feb '12

23 Feb '12

On Thu, 23 Feb 2012 20:31:09 GMT, hyc(a)symas.com wrote: > It seems unnecessary to document ldif-wrap in all of the commands, > since only ldapsearch actually produces LDIF output. No, controls can also request LDIF output. E.g. ldapmodify -e preread -o ldif-wrap=20 wraps after column... 22?? New ITS coming up. -- Hallvard

1 0

Re: (ITS#7177) [PATCH] various manpage fixes
by jvcelak＠redhat.com 23 Feb '12

23 Feb '12

> It seems unnecessary to document ldif-wrap in all of the commands, > since only > ldapsearch actually produces LDIF output. The option isn't relevant > for any of > the others. I know. Feel free to modify the changes as you wish. I just wanted to make the man page consistent across all tools, because the description of "-o" displayed with "ldaptool --help" is always the same. Jan

1 0

Re: (ITS#7177) [PATCH] various manpage fixes
by hyc＠symas.com 23 Feb '12

23 Feb '12

Jan Vcelak wrote: >> The -C option is deprecated and intentionally undocumented. > > OK, I've uploaded updated patches, which exclude '-C': > > ftp://ftp.openldap.org/incoming/jvcelak-20120223-0001-man-add-missing-optio… > ftp://ftp.openldap.org/incoming/jvcelak-20120223-0002-man-add-SASL_NOCANON-… > > Jan > Thanks. Some of this overlaps ITS#7152. Will take a look at both to see which I like better. ;) It seems unnecessary to document ldif-wrap in all of the commands, since only ldapsearch actually produces LDIF output. The option isn't relevant for any of the others. -- -- 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#7178) pcache ttr issues
by mhardin＠symas.com 23 Feb '12

23 Feb '12

Fix verified. You can close this one. Thanks! -Matt On Feb 22, 2012, at 1:47 PM, mhardin(a)symas.com wrote: > Full_Name: Matthew Hardin > Version: 2.4.29 > OS: Linux (Debian 6, x86_64) > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (170.215.93.127) > > > When proxycache overlay is configured with a time-to-refresh (TTR) value and the > entry being refreshed is no longer available on the remote server, the refresh > operation continues sending ldap search requests to the server, to which the > server responds with an error 2 and a text of "invalid deref". > > The following log excerpt is from the remote server: > > 4f3f7580 conn=1003 op=55 SRCH base="ou=people,dc=example,dc=com" scope=1 deref=0 > filter="(&(objectClass=posixAccount)(uidNumber=10001))" > 4f3f7580 conn=1003 op=55 SRCH attr=cn uid uidNumber gidNumber homeDirectory > userPassword loginShell gecos description objectClass > 4f3f7580 conn=1003 op=55 SEARCH RESULT tag=101 err=0 nentries=0 text= > 4f3f7580 conn=1003 op=56 SEARCH RESULT tag=101 err=2 nentries=0 text=invalid > deref" > > The old entry remains in the cache and is returned as the current value. > >

1 0

(ITS#7180) libmdb assertion error on slapadd
by quanah＠OpenLDAP.org 23 Feb '12

23 Feb '12

Full_Name: Quanah Gibson-Mount Version: 2.4.29 OS: Linux 2.6 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (75.108.184.39) >From slapadd: #################### 100.00% eta none elapsed none fast! slapadd: ../../../libraries/libmdb/mdb.c:3827: mdb_cursor_get: Assertion `mc' failed. Aborted

1 0

Re: (ITS#7177) [PATCH] various manpage fixes
by jvcelak＠redhat.com 23 Feb '12

23 Feb '12

> The -C option is deprecated and intentionally undocumented. OK, I've uploaded updated patches, which exclude '-C': ftp://ftp.openldap.org/incoming/jvcelak-20120223-0001-man-add-missing-optio… ftp://ftp.openldap.org/incoming/jvcelak-20120223-0002-man-add-SASL_NOCANON-… Jan

1 0

Re: (ITS#7178) pcache ttr issues
by mhardin＠symas.com 22 Feb '12

22 Feb '12

Logs uploaded to ftp/incoming: its7178_Remote_server_log.txt its7178cacheServerLog.txt Cheers, -Matt

1 0

Re: (ITS#7179) pcache ttr issues
by mhardin＠symas.com 22 Feb '12

22 Feb '12

This is a DUP of 7178 and should be closed. This was the result of clicking the "compose comment" button found on the ITS display screen. Seems like a malfunction, or at least a non-intuitive result. -Matt On Feb 22, 2012, at 4:02 PM, openldap-its(a)OpenLDAP.org wrote: > > *** THIS IS AN AUTOMATICALLY GENERATED REPLY *** > > Thanks for your report to the OpenLDAP Issue Tracking System. Your > report has been assigned the tracking number ITS#7179. > > One of our support engineers will look at your report in due course. > Note that this may take some time because our support engineers > are volunteers. They only work on OpenLDAP when they have spare > time. > > If you need to provide additional information in regards to your > issue report, you may do so by replying to this message. Note that > any mail sent to openldap-its(a)openldap.org with (ITS#7179) > in the subject will automatically be attached to the issue report. > > mailto:openldap-its@openldap.org?subject=(ITS#7179) > > You may follow the progress of this report by loading the following > URL in a web browser: > http://www.OpenLDAP.org/its/index.cgi?findid=7179 > > Please remember to retain your issue tracking number (ITS#7179) > on any further messages you send to us regarding this report. If > you don't then you'll just waste our time and yours because we > won't be able to properly track the report. > > Please note that the Issue Tracking System is not intended to > be used to seek help in the proper use of OpenLDAP Software. > Such requests will be closed. > > OpenLDAP Software is user supported. > http://www.OpenLDAP.org/support/ > > -------------- > Copyright 1998-2007 The OpenLDAP Foundation, All Rights Reserved. >

1 0

Re: (ITS#7178) pcache ttr issues
by mhardin＠symas.com 22 Feb '12

22 Feb '12

Log files uploaded to ftp/incoming: its7178cacheServerLog.txt its7178_Remote_server_log.txt Cheers, -Matt

1 0

(ITS#7179) pcache ttr issues
by mhardin＠symas.com 22 Feb '12

22 Feb '12

Full_Name: Matthew Hardin Version: 2.4.29 OS: Linux (Debian 6, x86_64) URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (170.215.93.127) When proxycache overlay is configured with a time-to-refresh (TTR) value and the entry being refreshed is no longer available on the remote server, the refresh operation continues sending ldap search requests to the server, to which the server responds with an error 2 and a text of "invalid deref". The following log excerpt is from the remote server: 4f3f7580 conn=1003 op=55 SRCH base="ou=people,dc=example,dc=com" scope=1 deref=0 filter="(&(objectClass=posixAccount)(uidNumber=10001))" 4f3f7580 conn=1003 op=55 SRCH attr=cn uid uidNumber gidNumber homeDirectory userPassword loginShell gecos description objectClass 4f3f7580 conn=1003 op=55 SEARCH RESULT tag=101 err=0 nentries=0 text= 4f3f7580 conn=1003 op=56 SEARCH RESULT tag=101 err=2 nentries=0 text=invalid deref" The old entry remains in the cache and is returned as the current value.

1 0

(ITS#7178) pcache ttr issues
by mhardin＠symas.com 22 Feb '12

22 Feb '12

Full_Name: Matthew Hardin Version: 2.4.29 OS: Linux (Debian 6, x86_64) URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (170.215.93.127) When proxycache overlay is configured with a time-to-refresh (TTR) value and the entry being refreshed is no longer available on the remote server, the refresh operation continues sending ldap search requests to the server, to which the server responds with an error 2 and a text of "invalid deref". The following log excerpt is from the remote server: 4f3f7580 conn=1003 op=55 SRCH base="ou=people,dc=example,dc=com" scope=1 deref=0 filter="(&(objectClass=posixAccount)(uidNumber=10001))" 4f3f7580 conn=1003 op=55 SRCH attr=cn uid uidNumber gidNumber homeDirectory userPassword loginShell gecos description objectClass 4f3f7580 conn=1003 op=55 SEARCH RESULT tag=101 err=0 nentries=0 text= 4f3f7580 conn=1003 op=56 SEARCH RESULT tag=101 err=2 nentries=0 text=invalid deref" The old entry remains in the cache and is returned as the current value.

1 0

Re: (ITS#7177) [PATCH] various manpage fixes
by hyc＠symas.com 22 Feb '12

22 Feb '12

jvcelak(a)redhat.com wrote: > Full_Name: Jan Vcelak > Version: 2.4.29 > OS: Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (209.132.186.34) > > > Hello, > > I have uploaded two patches with manual page fixes: > > ftp://ftp.openldap.org/incoming/jvcelak-20120222-0001-man-add-missing-optio… > > - typo in '-o' in --help output > - missing '-C' in ldapsearch and ldapcompare > - manpages all tools: > + add -o description (general options) > + add -N description (reverse DNS SASL host name canonicalization) > - manpages ldapsearch, ldapcompare: > + add -C (perform referral chasing) The -C option is deprecated and intentionally undocumented. -- -- 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

(ITS#7177) [PATCH] various manpage fixes
by jvcelak＠redhat.com 22 Feb '12

22 Feb '12

Full_Name: Jan Vcelak Version: 2.4.29 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (209.132.186.34) Hello, I have uploaded two patches with manual page fixes: ftp://ftp.openldap.org/incoming/jvcelak-20120222-0001-man-add-missing-optio… - typo in '-o' in --help output - missing '-C' in ldapsearch and ldapcompare - manpages all tools: + add -o description (general options) + add -N description (reverse DNS SASL host name canonicalization) - manpages ldapsearch, ldapcompare: + add -C (perform referral chasing) ftp://ftp.openldap.org/incoming/jvcelak-20120222-0002-man-add-SASL_NOCANON-… - add SASL_NOCANON option to ldap.conf(5) The attached files are derived from OpenLDAP Software. All of the modifications to OpenLDAP Software represented in the uploaded patches were developed by Red Hat. Red Hat has not assigned rights and/or interest in this work to any party. I, Jan Vcelak am authorized by Red Hat, my employer, to release this work under the following terms. Red Hat hereby place the following modifications to OpenLDAP Software (and only these modifications) into the public domain. Hence, these modifications may be freely used and/or redistributed for any purpose with or without attribution and/or other notice.

1 0

Re: (ITS#7160) MDB-back is not buildable on HP-UX 11.31
by hyc＠symas.com 21 Feb '12

21 Feb '12

Sascha.Kuehndel(a)deka.de wrote: > Hi, > > I have test the changes, now. > The Make file looks now correct. > But i needed to use the hack from Howard Chu, too. > > Now, openldap was build correct. Thanks for the confirmation. These fixes are now in git master. > > Thanks, > Sascha Kuehndel -- -- 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#7167) regression, ldap_result() returns -1
by jvcelak＠redhat.com 21 Feb '12

21 Feb '12

Perfect! This patch resolves the issue. Thank you, Howard! Jan ----- Original Message ----- > This is a multi-part message in MIME format. > --------------060206020501030606090605 > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > Content-Transfer-Encoding: 7bit > > Try this instead. > > Howard Chu wrote: > > Please test the attached patch and see if the problem is resolved, > > thanks. > >

1 0

Re: (ITS#7160) MDB-back is not buildable on HP-UX 11.31
by Sascha.Kuehndel＠deka.de 21 Feb '12

21 Feb '12

--_000_A8488806467B644782680A8469F29E2C01201F5849EXCCREX9dekag_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, I have test the changes, now. The Make file looks now correct. But i needed to use the hack from Howard Chu, too. Now, openldap was build correct. Thanks, Sascha Kuehndel --_000_A8488806467B644782680A8469F29E2C01201F5849EXCCREX9dekag_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable <html> <head> <meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Diso-8859-= 1"> <meta name=3D"Generator" content=3D"Microsoft Exchange Server">  <style></style> </head> <body> <font face=3D"Arial, sans-serif" size=3D"2"> <div>Hi,</div> <div> </div> <div>I have test the changes, now.</div> <div>The Make file looks now correct.</div> <div>But i needed to use the hack from Howard Chu, too.</div> <div> </div> <div>Now, openldap was build correct.</div> <div> </div> <div>Thanks,</div> <div>Sascha Kuehndel</div> <div> </div> </font> </body> </html> --_000_A8488806467B644782680A8469F29E2C01201F5849EXCCREX9dekag_--

1 0

(ITS#7176) slapindex -q -t segfaults with back-mdb
by quanah＠OpenLDAP.org 20 Feb '12

20 Feb '12

Full_Name: Quanah Gibson-Mount Version: 2.4.29 + ITS7174 OS: Linux 2.6 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (75.108.184.39) When running slapindex -q -t, back-mdb segfaults: Thread 1 (Thread 0x7ffff7fef700 (LWP 20316)): #0 0x00007ffff34a1b45 in mdb_midl_append (idp=0x8f1fa8, id=6) at ../../../libraries/libmdb/midl.c:148 ids = 0x0 #1 0x00007ffff34a1712 in mdb_drop0 (mc=0x8dcd80, subs=4) at ../../../libraries/libmdb/mdb.c:5990 ni = 0x7febf2556eb4 mx = {mc_next = 0x1104184c, mc_orig = 0x7ffff7de7722, mc_xcursor = 0x0, mc_txn = 0x8f1f80, mc_dbi = 5, mc_db = 0x8f20d8, mc_dbx = 0x8d8070, mc_dbflag = 0x80e4e0 "", mc_snum = 1, mc_top = 0, mc_flags = 16, mc_pg = {0x7febf2556000, 0x7fffffffe5f0, 0x0, 0x80e838, 0x7fffffffe3c0, 0x7fffffffe3d8, 0x100000000, 0x893590, 0x7ffff346d4e1, 0x7fffffffe5f0, 0x38, 0x3a0, 0x38, 0x7fffffffe5f0, 0x8afa90, 0x0, 0x7ffff6314e40, 0x7fffffffe480, 0x378, 0x7fffffffea50, 0x0, 0x0, 0x8dcd80, 0xa25d2c9e, 0x8dcf08, 0x7fffffffe420, 0x7ffff349d1c0, 0x8dcf08, 0x5ffffe690, 0x8f1f80, 0x8dcd80, 0x7fffffffe480}, mc_ki = { 507, 62281, 32767, 0, 58496, 65535, 32767, 0, 58528, 65535, 32767, 0, 0, 0, 5, 0, 8064, 143, 0, 0, 59376, 65535, 32767, 0, 888, 0, 0, 0, 53000, 141, 0, 0}} i = 20 rc = 0 #2 0x00007ffff34a1796 in mdb_drop (txn=0x8f1f80, dbi=5, del=0) at ../../../libraries/libmdb/mdb.c:6008 mc = 0x8dcd80 rc = 0 #3 0x00007ffff34753e8 in mdb_tool_entry_reindex (be=0x8afa90, id=0, adv=0x0) at tools.c:770 i = 0 mi = 0x7ffff2751010 rc = 0 e = 0x0 op = {o_hdr = 0x0, o_tag = 0, o_time = 0, o_tincr = 0, 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}} ohdr = {oh_opid = 0, oh_connid = 0, oh_conn = 0x0, oh_msgid = 0, oh_protocol = 0, oh_tid = 0, oh_threadctx = 0x0, oh_tmpmemctx = 0x0, oh_tmpmfuncs = 0x0, oh_counters = 0x0, oh_log_prefix = '\000' <repeats 255 times>} __PRETTY_FUNCTION__ = "mdb_tool_entry_reindex" #4 0x00000000004dc624 in slapindex (argc=0, argv=0x7fffffffea58) at slapindex.c:96 rtn = 32767 id = 0 rc = 0 progname = 0x51c4c0 "slapindex" ad = 0x10 adv = 0x0 __PRETTY_FUNCTION__ = "slapindex" #5 0x0000000000415a20 in main (argc=7, argv=0x7fffffffea58) at main.c:410 i = 3 no_detach = 0 rc = 1 urls = 0x0 username = 0x0 groupname = 0x0 sandbox = 0x0 syslogUser = 160 pid = 0 waitfds = {3817984, 0} g_argc = 7 g_argv = 0x7fffffffea58 configfile = 0x0 configdir = 0x0 serverName = 0x7fffffffecb8 "slapindex" serverMode = 1 scp = 0x0 scp_entry = 0x0 debug_unknowns = 0x0 syslog_unknowns = 0x0 serverNamePrefix = 0x4faa68 "" l = 140737488349486 slapd_pid_file_unlink = 0 slapd_args_file_unlink = 0 firstopt = 1 __PRETTY_FUNCTION__ = "main"

1 0

Re: (ITS#7167) regression, ldap_result() returns -1
by hyc＠symas.com 20 Feb '12

20 Feb '12

This is a multi-part message in MIME format. --------------060206020501030606090605 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Try this instead. Howard Chu wrote: > Please test the attached patch and see if the problem is resolved, thanks. > -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/ --------------060206020501030606090605 Content-Type: text/plain; charset=UTF-8; name="diff.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="diff.txt" diff --git a/libraries/libldap/ldap-int.h b/libraries/libldap/ldap-int.h index c558d2a..ad37250 100644 --- a/libraries/libldap/ldap-int.h +++ b/libraries/libldap/ldap-int.h @@ -622,6 +622,7 @@ LDAP_F (void) ldap_free_select_info( void *sip ); LDAP_F (void) ldap_mark_select_write( LDAP *ld, Sockbuf *sb ); LDAP_F (void) ldap_mark_select_read( LDAP *ld, Sockbuf *sb ); LDAP_F (void) ldap_mark_select_clear( LDAP *ld, Sockbuf *sb ); +LDAP_F (void) ldap_clear_select_write( LDAP *ld, Sockbuf *sb ); LDAP_F (int) ldap_is_read_ready( LDAP *ld, Sockbuf *sb ); LDAP_F (int) ldap_is_write_ready( LDAP *ld, Sockbuf *sb ); diff --git a/libraries/libldap/open.c b/libraries/libldap/open.c index 6b92ba6..a920953 100644 --- a/libraries/libldap/open.c +++ b/libraries/libldap/open.c @@ -344,7 +344,6 @@ ldap_init_fd( /* Add the connection to the *LDAP's select pool */ ldap_mark_select_read( ld, conn->lconn_sb ); - ldap_mark_select_write( ld, conn->lconn_sb ); *ldp = ld; return LDAP_SUCCESS; @@ -502,7 +501,6 @@ ldap_open_internal_connection( LDAP **ldp, ber_socket_t *fdp ) /* Add the connection to the *LDAP's select pool */ ldap_mark_select_read( ld, c->lconn_sb ); - ldap_mark_select_write( ld, c->lconn_sb ); /* Make this connection an LDAP V3 protocol connection */ rc = LDAP_VERSION3; diff --git a/libraries/libldap/os-ip.c b/libraries/libldap/os-ip.c index daa765e..2864256 100644 --- a/libraries/libldap/os-ip.c +++ b/libraries/libldap/os-ip.c @@ -966,6 +966,32 @@ ldap_mark_select_clear( LDAP *ld, Sockbuf *sb ) #endif } +void +ldap_clear_select_write( LDAP *ld, Sockbuf *sb ) +{ + struct selectinfo *sip; + ber_socket_t sd; + + sip = (struct selectinfo *)ld->ld_selectinfo; + + ber_sockbuf_ctrl( sb, LBER_SB_OPT_GET_FD, &sd ); + +#ifdef HAVE_POLL + /* for UNIX poll(2) */ + { + int i; + for(i=0; i < sip->si_maxfd; i++) { + if( sip->si_fds[i].fd == sd ) { + sip->si_fds[i].events &= ~POLL_WRITE; + } + } + } +#else + /* for UNIX select(2) */ + FD_CLR( sd, &sip->si_writefds ); +#endif +} + int ldap_is_write_ready( LDAP *ld, Sockbuf *sb ) diff --git a/libraries/libldap/request.c b/libraries/libldap/request.c index 88190a2..071391d 100644 --- a/libraries/libldap/request.c +++ b/libraries/libldap/request.c @@ -202,6 +202,7 @@ ldap_int_flush_request( /* sent -- waiting for a response */ ldap_mark_select_read( ld, lc->lconn_sb ); + ldap_clear_select_write( ld, lc->lconn_sb ); } return 0; } diff --git a/libraries/libldap/result.c b/libraries/libldap/result.c index b6e8e75..7241df9 100644 --- a/libraries/libldap/result.c +++ b/libraries/libldap/result.c @@ -302,7 +302,7 @@ wait4msg( if ( ber_sockbuf_ctrl( lc->lconn_sb, LBER_SB_OPT_DATA_READY, NULL ) ) { - lc_ready = 1; + lc_ready = 2; /* ready at ber level, not socket level */ break; } } @@ -373,8 +373,8 @@ wait4msg( } } LDAP_MUTEX_UNLOCK( &ld->ld_req_mutex ); - /* Quit looping if no one handled any events */ - if (!serviced) + /* Quit looping if no one handled any socket events */ + if (!serviced && lc_ready == 1) rc = -1; } LDAP_MUTEX_UNLOCK( &ld->ld_conn_mutex ); --------------060206020501030606090605--

1 0

Re: (ITS#7172) SEGFAULT in openldap-2.4.28 & 2.4.29
by david.coutadeur＠linagora.com 20 Feb '12

20 Feb '12

Hi, Concerning the cpu : model name : Intel(R) Xeon(R) CPU L5640 @ 2.27GHz However, OpenLDAP is used in a virtual machine, with only one dedicated core. This is 32 bits version of OpenLDAP, on a 32 bits OS. Linux OS : Red Hat Enterprise Linux Server release 5.7 (Tikanga) kernel : 2 2.6.18-274.3.1.el5 You can get the server configuration below. Concerning the client, you can find the source code here : http://loadtesting.sourceforge.net/index.php?lang=en # ---------------------------------------------------------------------------- # Global section # ---------------------------------------------------------------------------- sizelimit 15000 allow bind_v2 password-hash {SSHA} threads 8 loglevel 256 serverID 2 include /opt/openldap/etc/openldap/inc_shemas/slapd-schemas.conf pidfile /opt/openldap/var/run/slapd.pid argsfile /opt/openldap/var/run/slapd.args # ACLs definition (cutted here) ####################################################################### # SSL definitions ####################################################################### # Definition of cert files # --------------------------------- TLSCipherSuite HIGH:MEDIUM:+SSLv2 TLSCACertificateFile /usr/local/openldap/etc/certs/ca.cert TLSCertificateFile /usr/local/openldap/etc/certs/ldap-master-2.cert TLSCertificateKeyFile /usr/local/openldap/etc/certs/ldap-master-2.key TLSVerifyClient never ####################################################################### # BDB database definitions ####################################################################### database monitor ####################################################################### # suffix dc=example,dc=com # -------------------- ####################################################################### database bdb directory /opt/openldap/var/openldap-data # some indexes # ---------------------------------------------------------------------------- # root suffix # ---------------------------------------------------------------------------- suffix "dc=example,dc=com" checkpoint 512 10 # ---------------------------------------------------------------------------- # cache settings # ---------------------------------------------------------------------------- cachesize 60000 dncachesize 60000 idlcachesize 60000 cachefree 100 rootdn "cn=Manager,dc=example,dc=com" rootpw secret # Password policy : hash the clear passwords overlay ppolicy ppolicy_hash_cleartext # ---------------------------------------------------------------------------- # REPLICATION definitions # ---------------------------------------------------------------------------- ####################################################################### # I am a master (provider) # ------------------------------------------ overlay syncprov syncprov-checkpoint 100 10 syncprov-sessionlog 100 # syncrepl directive (consummer infos) # ------------------------------------------ syncrepl rid=001 provider=ldap://ldap-master-1.example.com bindmethod=simple binddn="uid=ReplicationMaster,ou=Replication,ou=Special Users,dc=example,dc=com" credentials=secret searchbase="dc=example,dc=com" schemachecking=on type=refreshAndPersist retry="60 +" mirrormode on # ---------------------------------------------------------------------------- # limits # ---------------------------------------------------------------------------- limits dn.exact="uid=ReplicationMaster,ou=Replication,ou=Special Users,dc=example,dc=com" size=unlimited time=unlimited limits dn.exact="uid=ReplicationHub,ou=Replication,ou=Special Users,dc=example,dc=com" size=unlimited time=unlimited limits dn.exact="uid=ReplicationLSC,ou=Replication,ou=Special Users,dc=example,dc=com" size=unlimited time=unlimited ####################################################################### # suffix o=edition # ---------------- ####################################################################### database bdb directory /opt/openldap/var/openldap-data-edition # some indexes # ---------------------------------------------------------------------------- # root suffix # ---------------------------------------------------------------------------- suffix "o=edition" checkpoint 512 10 # ---------------------------------------------------------------------------- # cache settings # ---------------------------------------------------------------------------- cachesize 50000 dncachesize 50000 idlcachesize 50000 cachefree 100 # ---------------------------------------------------------------------------- # rootdn # ---------------------------------------------------------------------------- # Cleartext passwords, especially for the rootdn, should # be avoid. See slappasswd(8) and slapd.conf(5) for details. # Use of strong authentication encouraged. rootdn "cn=Manager,o=edition" rootpw secret # Password policy : hash the clear passwords overlay ppolicy ppolicy_hash_cleartext ####################################################################### # REPLICATION definitions ####################################################################### # I am a master (provider) # ------------------------------------------ overlay syncprov syncprov-checkpoint 100 10 syncprov-sessionlog 100 # syncrepl directive (consummer infos) # ------------------------------------------ syncrepl rid=002 provider=ldap://vspar-ldap-master-1.example.com bindmethod=simple binddn="uid=ReplicationMaster,ou=Replication,ou=Special Users,dc=example,dc=com" credentials=secret searchbase="o=edition" schemachecking=on type=refreshAndPersist retry="60 +" mirrormode on # ---------------------------------------------------------------------------- # Limits for current BDB # ---------------------------------------------------------------------------- limits dn.exact="uid=ReplicationMaster,ou=Replication,ou=Special Users,dc=example,dc=com" size=unlimited time=unlimited limits dn.exact="uid=ReplicationHub,ou=Replication,ou=Special Users,dc=example,dc=com" size=unlimited time=unlimited limits dn.exact="uid=ReplicationLSC,ou=Replication,ou=Special Users,dc=example,dc=com" size=unlimited time=unlimited Le 17/02/2012 19:00, Howard Chu a écrit : > dcoutadeur(a)linagora.com wrote: >> Full_Name: dcoutadeur >> Version: 2.4.28 >> OS: Red Hat Enterprise Linux Server release 5.7 (Tikanga) >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (109.197.176.10) >> >> >> >> Hello, >> >> >> I had a segfault in the last git version of OpenLDAP, after 10 to 15 >> tests, each >> interrupted by Ctrl+C. (see what's a test below) >> The segfault is also reproduced in version 2.4.28. >> >> I think I won't be able to reproduce the bug with Valgrind. > > If you expect us to try to reproduce the bug, you'll have to provide > more information. Since this crash is in syncprov there's obviously at > least two servers involved; what are their configurations? What hardware > are they running on (in particular, how many CPU cores per server)? > Since you're using a custom client, can you provide the client source code? >> >> Thank you in advance for any help. >> >> D. >> >> >> Note : A test is 100 times 100 threads, each doing a bind, an add, a >> modify, a >> delete, and a logout. >> >> >> >> >> >> (gdb) bt full >> #0 sp_avl_cmp (c1=0x8b4004c8, c2=0xa37cf28) at syncprov.c:366 >> rc =<value optimized out> >> #1 0x081afe3e in avl_delete (root=0xa255648, data=0x8b4004c8, >> fcmp=0x81948a0<sp_avl_cmp>) at avl.c:197 >> p =<value optimized out> >> q =<value optimized out> >> r =<value optimized out> >> top =<value optimized out> >> side =<value optimized out> >> side_bf =<value optimized out> >> shorter =<value optimized out> >> nside =<value optimized out> >> pptr = {0x89908, 0x0, 0x0, 0x0, 0xe8043c, 0x0, 0xfdc, >> 0x8d994858, 0xe7b95c, 0xfdc, 0xa372570, 0x0, 0xa288350, >> 0xe8043c, 0xa372570, 0x8d994878, 0xe7c324, 0xfdc, 0xa372570, >> 0x0, 0xe7af2c, 0x8cb9136e, 0x81b3634, 0x0, 0xe8043c, >> 0xe, 0xa3d3a40, 0x8d9948b8, 0xe7d081, 0xa3e3618, 0x8cb91358, >> 0x823c27} >> pdir = >> "\000\000\000\000lI\231\215\064\066\033\bn>\000\000\244\345t\000\310\004@\213\b\346\067\n\310H\231\215" >> >> depth = 0 >> #2 0x08199f7f in syncprov_op_cleanup (op=0xa37e608, rs=0x8d995108) at >> syncprov.c:1401 >> cb = 0x8cb91258 >> opc = 0x8cb91268 >> si = 0xa255610 >> sm = 0xa255688 >> snext =<value optimized out> >> mt = 0x8b4004c8 >> #3 0x08089654 in slap_cleanup_play (op=0xa37e608, rs=0x8d995108) at >> result.c:541 >> sc_next = 0x8d994dec >> sc = 0x8cb91258 >> scp = 0x8d994928 >> #4 0x0808a150 in send_ldap_response (op=0xa37e608, rs=0x8d995108) at >> result.c:733 >> berbuf = { >> buffer = "\000\000\001\000\000\001\000\000\377\377\377\377", >> '\000'<repeats 12 times>, >> "f\023\271\214\064#\271\214\000\000\000\000f\023\271\214p%7\n\000\000\000\000\314I\231\215\001\000\000\000\000\000\000\000\314mK\236x\271\347\000\001\000\000\000`+@\213D`K\236\230\063\066\n\250<6\n\000\000\000\000\000\000\000\000\005\000\000\000P7@\213`\343\070\n\000\000\000\000\n\000\000\000(\234\200\330\000\000\000\000\000\000\000\000@4\"\000\000\000\000\000(\234\200\330\210J\231\215\270\214 >> >> \000\230\063\066\n`+@\213\314mK\236\r\000\000\000\001\000\000\000\021\217;O(\234\200\330\000\000\000\000`&%\n`&%\n8J\231\215b\f\"\000\224mK\236\230\063\066\n(\234\200أ\347\022\b\a", >> >> '\000'<repeats 31 times>, "D'%\n\224mK\236\000\000\000", >> ialign = 65536, lalign = 65536, falign = 9.18354962e-41, >> dalign = 5.4323095486619588e-312, >> palign = 0x10000<Address 0x10000 out of bounds>} >> ber =<value optimized out> >> rc = 32768 >> bytes = 14 >> __PRETTY_FUNCTION__ = "send_ldap_response" >> #5 0x0808af1f in slap_send_ldap_result (op=0xa37e608, rs=0x8d995108) at >> result.c:860 >> tmp = 0x0 >> otext = 0x0 >> oref = 0x0 >> __PRETTY_FUNCTION__ = "slap_send_ldap_result" >> #6 0x0812bde5 in bdb_add (op=0xa37e608, rs=0x8d995108) at add.c:511 >> pdn = {bv_len = 23, bv_val = 0x8b40372f >> "ou=people,dc=afp,dc=com"} >> p = 0x8fc4c0fc >> oe = 0x8fc4c804 >> ei = 0xa37d1c8 >> textbuf = "\000\000\000\000\320O\"\n", '\000'<repeats 48 >> times>, "\001", '\000'<repeats 198 times> >> children = 0xa223b20 >> entry = 0xa223980 >> ltid = 0x0 >> lt2 = 0x8b402bf0 >> eid = 57976 >> opinfo = {boi_oe = {oe_next = {sle_next = 0x8d99509c}, oe_key = >> 0x0}, boi_txn = 0x8b402b60, boi_locks = 0x0, >> boi_err = 0, boi_acl_cache = 0 '\000', boi_flag = 0 '\000'} >> lock = {off = 133260, ndx = 772, gen = 2004, mode = >> DB_LOCK_READ} >> num_retries = 0 >> success = 0 >> postread_ctrl = 0x0 >> ctrls = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0} >> num_ctrls = 0 >> #7 0x080e33a1 in overlay_op_walk (op=0xa37e608, rs=0x8d995108, >> which=op_add, oi=0xa254ff0, on=0xa255508) at backover.c:671 >> rc = 32768 >> #8 0x080e3a0a in over_op_func (op=0xa37e608, rs=0x8d995108, >> which=op_add) at backover.c:723 >> oi = 0xa254ff0 >> on = 0xa255508 >> be = 0xa252560 >> db = {bd_info = 0x821d41c, bd_self = 0xa252560, >> be_ctrls = >> "\000\001\001\001\000\001\000\000\001\000\000\001\001\000\001\001\000\000\000\000\001\000\001\000\000\000\000\000\000\000\000\000\001", >> >> be_flags = 563464, 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 = >> 0xa288350, be_nsuffix = 0xa288368, be_schemadn = { >> bv_len = 0, bv_val = 0x0}, be_schemandn = {bv_len = 0, >> bv_val = 0x0}, be_rootdn = {bv_len = 24, >> bv_val = 0xa287648 "cn=Manager,dc=afp,dc=com"}, be_rootndn = >> {bv_len = 24, >> bv_val = 0xa2876d0 "cn=manager,dc=afp,dc=com"}, be_rootpw = >> {bv_len = 38, >> bv_val = 0xa2876f0 >> "{SSHA}rEmMhg3MU5xkQX5Ng92tH4WzGMlA+nGU"}, be_max_deref_depth = 15, >> be_def_limit = { >> lms_t_soft = 3600, lms_t_hard = 0, lms_s_soft = 15000, >> lms_s_hard = 0, lms_s_unchecked = -1, lms_s_pr = 0, >> lms_s_pr_hide = 0, lms_s_pr_total = 0}, be_limits = >> 0xa255748, be_acl = 0x0, 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 = 0xa363388, be_pcl_mutex = {__data = >> {__lock = 0, __count = 0, __owner = 0, __kind = 0, >> __nusers = 0, {__spins = 0, __list = {__next = 0x0}}}, >> __size = '\000'<repeats 23 times>, __align = 0}, >> be_syncinfo = 0xa28aec8, be_pb = 0x0, be_cf_ocs = 0x821f840, >> be_private = 0xa252660, be_next = { >> stqe_next = 0xa288538}} >> cb = {sc_next = 0x0, sc_response = 0x80e30e0 >> <over_back_response>, sc_cleanup = 0, sc_private = 0xa254ff0} >> sc =<value optimized out> >> rc =<value optimized out> >> __PRETTY_FUNCTION__ = "over_op_func" >> #9 0x08081129 in fe_op_add (op=0xa37e608, rs=0x8d995108) at add.c:334 >> repl_user = 0 >> rc =<value optimized out> >> bd = 0x82234c0 >> textbuf = >> "\000\000\000\000\000\000\000\000\060[\231\215\000\000\000\000\035\000\000\000\020\070@\213\001\000\000\000xN\231\215\270\026@\213(I\"\n\002\000\000\000\250N\231\215\255\214\v\b\270\026@\213\224N\231\215\001\000\000\000\000\000\000\000x9@\213\000\000\000\000\n\000\000\000\001\000\000\000\340\067@\213\n\000\000\000\060\070@\213\320\026@\213(I\"\n\270\026@\213\370N\231\215oc\t\b\002\000\000\000X( >> >> \n\370N\231\215\321_\t\bh\234!\n\240\066@\213'<\202\000\000\000\000\000\f\000\000\000W.@\213n>\000\000\244\345t\000\320O\"\n\320O\"\n\370N\231\215\035\205q\000 >> >> .\"\b\314h\032\216\030O\231\215\245\063\b\b >> .\"\b\240\066@\213\000\000\000\000\270\026@\213\244i\032\216\000\000\000\000HO\231\215\267\r\b\b\320O\"\n\320O\"\n\001\000\000\000HO\231\215\020\000\000\000\340h\032\216\377\377\377\377" >> >> __PRETTY_FUNCTION__ = "fe_op_add" >> #10 0x08081a13 in do_add (op=0xa37e608, rs=0x8d995108) at add.c:194 >> ber =<value optimized out> >> last = 0x8b402e71 "" >> dn = {bv_len = 38, bv_val = 0x8b402d98 >> "uid=dcoutadeur,ou=People,dc=afp,dc=com"} >> len = 28 >> tag =<value optimized out> >> modlist = 0x8b4015f0 >> modtail = 0x8b403694 >> tmp = {sml_mod = {sm_desc = 0x80ce5ca, sm_values = 0x8b4036a0, >> sm_nvalues = 0x0, sm_numvals = 2375635128, >> sm_op = 0, sm_flags = 0, sm_type = {bv_len = 12, bv_val = >> 0x8b402e57 "userPassword"}}, sml_next = 0x823c27} >> textbuf = >> "\025\000\000\000\310\031@\213\b\026@\213\006\340(\000\220[\231\215\000\000\000\000\000\000\000\000\020\000@\213\025\000\000\000\310\031@\213\310+@\213\005\070/\000\200O@\213T\245(\000\000\000\000\000\020\000@\213\364\237\067\000\220[\231\215\000\000\000\000\233\071@\213@:=\n\370O\231\215T\213\202\000b\213\202\000;\334\347\000\"\000\000\000\233\071@\213\b\000\000\000\201\354(\000\fP\231\215<\004\350\000\270P\231\215\312\315\347\000\370\326\070\n\233\071@\213\b\000\000\000\001\200\255\373\b\347\067\n@\000\000\000\243P\231\215@\000@\213\026\347\067\n@\000@\213\b\347\067\n@\261\067\000,\000\000\000\020\000@\213", >> >> '\000'<repeats 20 times>, >> "5\000\000\000@\000@\213\000\000\000\000\340\021@\213\000\000\000\000\000\000\000\000\260+@\213\000\000\000\000\001\000\000\000\004\000\020\000\350Q\231\215\310P\231\215" >> >> rc =<value optimized out> >> freevals =<value optimized out> >> oex = {oe = {oe_next = {sle_next = 0x0}, oe_key = 0x8081330}, >> oe_db = 0x0} >> #11 0x0807988c in connection_operation (ctx=0x8d9951e8, arg_v=0xa37e608) >> at connection.c:1150 >> rc =<value optimized out> >> cancel =<value optimized out> >> rs = {sr_type = REP_RESULT, sr_tag = 105, 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} >> tag = 104 >> opidx = SLAP_OP_ADD >> conn = 0xb7f3bc10 >> memctx = 0xa372570 >> memctx_null = 0x0 >> __PRETTY_FUNCTION__ = "connection_operation" >> #12 0x0807a0fd in connection_read_thread (ctx=0x8d9951e8, argv=0x22) at >> connection.c:1286 >> s =<value optimized out> >> #13 0x00717a24 in ldap_int_thread_pool_wrapper (xpool=0xa2265c8) at >> tpool.c:688 >> task = 0xa382e10 >> work_list =<value optimized out> >> ctx = {ltu_id = 2375637904, ltu_key = {{ltk_key = 0x80ce400, >> ltk_data = 0xa372570, >> ltk_free = 0x80ce430<slap_sl_mem_destroy>}, {ltk_key = >> 0xa363398, ltk_data = 0xa371a88, >> ltk_free = 0x812e4c0<bdb_reader_free>}, {ltk_key = >> 0x8078320, ltk_data = 0xa37de68, >> ltk_free = 0x80783f0<conn_counter_destroy>}, {ltk_key = >> 0x808dde0, ltk_data = 0x0, >> ltk_free = 0x808dbf0<slap_op_q_destroy>}, {ltk_key = 0x0, >> ltk_data = 0x0, ltk_free = 0}<repeats 28 times>}} >> kctx =<value optimized out> >> keyslot = 241 >> hash = 5278961 >> __PRETTY_FUNCTION__ = "ldap_int_thread_pool_wrapper" >> #14 0x00821832 in start_thread () from /lib/libpthread.so.0 >> No symbol table info available. >> #15 0x002f746e in clone () from /lib/libc.so.6 >> No symbol table info available. >> >> >> >> >> > >

1 0

Re: (ITS#7175) Segv during cache entry delete pcache+back-mdb
by mhardin＠symas.com 19 Feb '12

19 Feb '12

I agree. Based on the timestamps it looks like we found them about an hour apart :p -Matt On Feb 19, 2012, at 5:30 PM, Quanah Gibson-Mount wrote: > Looks like a dupe of 7174 to me. > > --Quanah > > On Feb 19, 2012, at 3:26 PM, mhardin(a)symas.com wrote: > >> Full_Name: Matthew Hardin >> Version: 2.4.29 >> OS: Linux (Debian 6) >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (170.215.93.127) >> >> >> During a cache delete operation (TTL expired) a segv is raised. >> >> Log and backtrace follow: >> >> >> 4f41809b DELETING ENTRY TEMPLATE=7d824524-ef99-1030-9d9b-fbe800313ae3 >> 4f41809b ==> mdb_delete: cn=managers,ou=group,dc=example,dc=com >> 4f41809b slap_queue_csn: queing 0x7fffb3e36150 >> 20120219230707.188204Z#000000#000#000000 >> 4f41809b mdb_dn2entry("ou=group,dc=example,dc=com") >> 4f41809b => mdb_dn2id("ou=group,dc=example,dc=com") >> 4f41809b <= mdb_dn2id: got id=0x4 >> 4f41809b => mdb_entry_decode: >> 4f41809b <= mdb_entry_decode >> 4f41809b mdb_dn2entry("cn=managers,ou=group,dc=example,dc=com") >> 4f41809b => mdb_dn2id("cn=managers,ou=group,dc=example,dc=com") >> 4f41809b <= mdb_dn2id: got id=0x5 >> 4f41809b => mdb_entry_decode: >> 4f41809b <= mdb_entry_decode >> 4f41809b => access_allowed: delete access to "ou=Group,dc=example,dc=com" >> "children" requested >> 4f41809b <= root access granted >> 4f41809b => access_allowed: delete access granted by manage(=mwrscxd) >> 4f41809b => access_allowed: delete access to >> "cn=managers,ou=Group,dc=example,dc=com" "entry" requested >> 4f41809b <= root access granted >> 4f41809b => access_allowed: delete access granted by manage(=mwrscxd) >> 4f41809b => mdb_dn2id_delete 0x5 >> 4f41809b <= mdb_dn2id_delete 0x5: 0 >> 4f41809b => index_entry_del( 5, "cn=managers,ou=Group,dc=example,dc=com" ) >> 4f41809b mdb_idl_delete_keys: 5 [0096defd] >> 4f41809b mdb_idl_delete_keys: 5 [8cc4ebff] >> >> Program received signal SIGSEGV, Segmentation fault. >> [Switching to Thread 0x7fffb3e37700 (LWP 12696)] >> 0x0000000000586b8b in lutil_str2bin (in=0x7fffb3e35e10, out=0x7fffb3e35e00, >> ctx=0xbb8b70) at /home/matth/suum4x/ldap24/libraries/liblutil/utils.c:812 >> 812 /home/matth/suum4x/ldap24/libraries/liblutil/utils.c: No such file or >> directory. >> >> (gdb) thr apply all bt >> >> Thread 3 (Thread 0x7fffb3e37700 (LWP 12696)): >> #0 0x0000000000586b8b in lutil_str2bin (in=0x7fffb3e35e10, >> out=0x7fffb3e35e00, ctx=0xbb8b70) >> at /home/matth/suum4x/ldap24/libraries/liblutil/utils.c:812 >> #1 0x000000000048fe9f in integerVal2Key (in=0xbb9370, key=0xbb93c8, >> tmp=0x7fffb3e35eb0, ctx=0xbb8b70) >> at /home/matth/suum4x/ldap24/servers/slapd/schema_init.c:2545 >> #2 0x000000000049029c in integerIndexer (use=163, flags=4, syntax=0x89e3f0, >> mr=0x8a3c50, prefix=0x8b1158, values=0xbb9370, keysp=0x7fffb3e35f90, >> ctx=0xbb8b70) at /home/matth/suum4x/ldap24/servers/slapd/schema_init.c:2634 >> #3 0x000000000053d589 in indexer (op=0x7fffb3e36480, txn=0xccd410, >> ai=0x91f8c0, ad=0x8b1280, atname=0x8b1158, vals=0xbb9370, id=5, opid=2, >> mask=4) at /home/matth/suum4x/ldap24/servers/slapd/back-mdb/index.c:211 >> #4 0x000000000053d96a in index_at_values (op=0x7fffb3e36480, txn=0xccd410, >> ad=0x8b1280, type=0x8b10f0, tags=0x8b12a0, vals=0xbb9370, id=5, opid=2) >> at /home/matth/suum4x/ldap24/servers/slapd/back-mdb/index.c:337 >> #5 0x000000000053daf1 in mdb_index_values (op=0x7fffb3e36480, txn=0xccd410, >> desc=0x8b1280, vals=0xbb9370, id=5, opid=2) >> at /home/matth/suum4x/ldap24/servers/slapd/back-mdb/index.c:386 >> #6 0x000000000053dfb9 in mdb_index_entry (op=0x7fffb3e36480, txn=0xccd410, >> opid=2, e=0xbb9178) >> at /home/matth/suum4x/ldap24/servers/slapd/back-mdb/index.c:558 >> #7 0x00000000005324e1 in mdb_delete (op=0x7fffb3e36480, rs=0x7fffb3e36340) >> at /home/matth/suum4x/ldap24/servers/slapd/back-mdb/delete.c:348 >> #8 0x0000000000554935 in remove_query_data (op=0x7fffb3e36480, >> query_uuid=0xcc3090) >> at /home/matth/suum4x/ldap24/servers/slapd/overlays/pcache.c:1838 >> #9 0x0000000000559ce4 in consistency_check (ctx=0x7fffb3e36b90, arg=0x995050) >> at /home/matth/suum4x/ldap24/servers/slapd/overlays/pcache.c:3579 >> #10 0x00007ffff7b8fb32 in ldap_int_thread_pool_wrapper (xpool=0x8b3ae0) >> at /home/matth/suum4x/ldap24/libraries/libldap_r/tpool.c:688 >> #11 0x00007ffff66f98ba in start_thread () from /lib/libpthread.so.0 >> #12 0x00007ffff646102d in clone () from /lib/libc.so.6 >> #13 0x0000000000000000 in ?? () >> >> Thread 2 (Thread 0x7fffb4638700 (LWP 12695)): >> #0 0x00007ffff6461623 in epoll_wait () from /lib/libc.so.6 >> #1 0x000000000043e986 in slapd_daemon_task (ptr=0x7fffffffe528) >> at /home/matth/suum4x/ldap24/servers/slapd/daemon.c:2539 >> #2 0x00007ffff66f98ba in start_thread () from /lib/libpthread.so.0 >> #3 0x00007ffff646102d in clone () from /lib/libc.so.6 >> #4 0x0000000000000000 in ?? () >> >> ---Type <return> to continue, or q <return> to quit--- >> Thread 1 (Thread 0x7ffff7fef700 (LWP 12692)): >> #0 0x00007ffff66fabe5 in pthread_join () from /lib/libpthread.so.0 >> #1 0x00007ffff7b91040 in ldap_pvt_thread_join (thread=140736219809536, >> thread_return=0x0) >> at /home/matth/suum4x/ldap24/libraries/libldap_r/thr_posix.c:197 >> #2 0x000000000043fab8 in slapd_daemon () >> at /home/matth/suum4x/ldap24/servers/slapd/daemon.c:2930 >> #3 0x000000000041d43b in main (argc=3, argv=0x7fffffffe778) >> at /home/matth/suum4x/ldap24/servers/slapd/main.c:1011 >> (gdb) >> >> ## >> ## SUUM v4 slapd Configuration File. Adjust settings as needed for your >> ## deployment. >> ## >> include "/opt/suum/etc/schema/core.schema" >> include "/opt/suum/etc/schema/cosine.schema" >> include "/opt/suum/etc/schema/inetorgperson.schema" >> include "/opt/suum/etc/schema/misc.schema" >> include "/opt/suum/etc/schema/rfc2307bis.schema" >> include "/opt/suum/etc/schema/ldapns.schema" >> >> #TLSCACertificateFile "/opt/suum/ssl/cacert.pem" >> >> pidfile "/var/symas/suum/slapd.pid" >> argsfile "/var/symas/suum/slapd.args" >> >> modulepath "/opt/suum/lib64/modules" >> moduleload nssov.la >> >> access to dn="" by * read >> access to * >> by self write >> by users read >> by anonymous auth >> >> database ldap >> suffix "dc=example,dc=com" >> rootdn "dc=example,dc=com" >> uri ldap://xxxxxxx >> idassert-bind bindmethod=simple >> binddn=cn=proxy,ou=restricted,dc=example,dc=com >> credentials=secret >> >> overlay nssov >> nssov-pam userhost userservice usergroup >> >> nssov-ssd passwd ldap:///ou=People,dc=example,dc=com??one >> nssov-ssd shadow ldap:///ou=People,dc=example,dc=com??one >> nssov-ssd group ldap:///ou=Group,dc=example,dc=com??one >> nssov-ssd hosts ldap:///ou=Hosts,dc=example,dc=com??one >> nssov-ssd services ldap:///ou=Services,dc=example,dc=com??one >> nssov-ssd networks ldap:///ou=Networks,dc=example,dc=com??one >> nssov-ssd protocols ldap:///ou=Protocols,dc=example,dc=com??one >> nssov-ssd rpc ldap:///ou=Rpc,dc=example,dc=com??one >> nssov-ssd ethers ldap:///ou=Hosts,dc=example,dc=com??one >> nssov-ssd netgroup ldap:///ou=Netgroup,dc=example,dc=com??one >> nssov-ssd aliases ldap:///ou=Aliases,dc=example,dc=com??one >> >> overlay pcache >> response-callback head >> >> pcache mdb 500000 11 1000 300 >> >> pcachePersist FALSE >> >> pcacheAttrset 0 cn uid uidNumber gidNumber >> homeDirectory userPassword loginShell >> gecos description objectClass >> pcacheAttrset 1 uid userPassword shadowLastChange shadowMin >> shadowMax shadowWarning shadowInactive >> shadowExpire shadowFlag description objectClass >> pcacheAttrset 2 cn gidNumber userPassword memberUid >> uniqueMember description objectClass >> pcacheAttrset 3 cn ipHostNumber l description >> manager objectClass >> pcacheAttrset 4 cn ipServicePort ipServiceProtocol description >> objectClass >> pcacheAttrset 5 cn ipNetworkNumber ipNetmaskNumber l >> description manager objectClass >> pcacheAttrset 6 cn ipProtocolNumber description objectClass >> >> pcacheAttrset 7 cn oncRpcNumber description objectClass >> >> pcacheAttrset 8 cn macAddress objectClass >> >> pcacheAttrset 9 cn nisNetgroupTriple memberNisNetgroup description >> objectClass >> pcacheAttrset 10 cn rfc822MailMember objectClass >> >> pcacheTemplate >> (&(objectClass=)(uid=)) 0 60 >> >> pcacheTemplate >> (&(objectClass=)(uidNumber=)) 0 60 >> >> pcacheTemplate >> (objectClass=) 0 60 >> >> pcacheTemplate >> (&(objectClass=)(uid=)) 1 60 >> >> pcacheTemplate >> (objectClass=) 2 60 >> >> pcacheTemplate >> (&(objectClass=)(cn=)) 2 60 >> >> pcacheTemplate >> (&(objectClass=)(gidNumber=)) 2 60 >> >> pcacheTemplate >> (&(objectClass=)(|(memberUid=)(uniqueMember=)) 2 60 >> >> pcacheTemplate >> (objectClass=) 3 60 >> >> pcacheTemplate >> (&(objectClass=)(cn=)) 3 60 >> >> pcacheTemplate >> (&(objectClass=)(ipHostNumber=)) 3 60 >> >> pcacheTemplate >> (objectClass=) 4 60 >> >> pcacheTemplate >> (&(objectClass=)(cn=)) 4 60 >> >> pcacheTemplate >> (&(objectClass=)(ipServicePort=)) 4 60 >> >> pcacheTemplate >> (&(objectClass=)(cn=)(ipServiceProtocol=)) 4 60 >> >> pcacheTemplate >> (&(objectClass=)(ipServicePort=)(ipServiceProtocol=)) 4 60 >> >> pcacheTemplate >> (objectClass=) 5 60 >> >> pcacheTemplate >> (&(objectClass=)(cn=)) 5 60 >> >> pcacheTemplate >> (&(objectClass=)(ipNetworkNumber=)) 5 60 >> >> pcacheTemplate >> (objectClass=) 6 60 >> >> pcacheTemplate >> (&(objectClass=)(cn=)) 6 60 >> >> pcacheTemplate >> (&(objectClass=)(ipProtocolNumber=)) 6 60 >> >> pcacheTemplate >> (objectClass=) 7 60 >> >> pcacheTemplate >> (&(objectClass=)(cn=)) 7 60 >> >> pcacheTemplate >> (&(objectClass=)(oncRpcNumber=)) 7 60 >> >> pcacheTemplate >> (&(objectClass=)(cn=)) 8 60 >> >> pcacheTemplate >> (&(objectClass=)(macAddress=)) 8 60 >> >> pcacheTemplate >> (&(objectClass=)(cn=)) 9 60 >> >> pcacheTemplate >> (&(objectClass=)(cn=)) 10 60 >> >> directory "/var/symas/suum/cache" >> >> maxsize 1073741824 >> >> index default eq >> index objectClass >> index cn,uid,uidNumber,gidNumber >> index memberUid,uniqueMember >> index ipHostNumber,ipServicePort,ipServiceProtocol >> index ipNetworkNumber,ipProtocolNumber >> index oncRpcNumber,macAddress >> >> # Monitor database >> database monitor >>

1 0

Re: (ITS#7175) Segv during cache entry delete pcache+back-mdb
by quanah＠zimbra.com 19 Feb '12

19 Feb '12

Looks like a dupe of 7174 to me. --Quanah On Feb 19, 2012, at 3:26 PM, mhardin(a)symas.com wrote: > Full_Name: Matthew Hardin > Version: 2.4.29 > OS: Linux (Debian 6) > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (170.215.93.127) > > > During a cache delete operation (TTL expired) a segv is raised. > > Log and backtrace follow: > > > 4f41809b DELETING ENTRY TEMPLATE=7d824524-ef99-1030-9d9b-fbe800313ae3 > 4f41809b ==> mdb_delete: cn=managers,ou=group,dc=example,dc=com > 4f41809b slap_queue_csn: queing 0x7fffb3e36150 > 20120219230707.188204Z#000000#000#000000 > 4f41809b mdb_dn2entry("ou=group,dc=example,dc=com") > 4f41809b => mdb_dn2id("ou=group,dc=example,dc=com") > 4f41809b <= mdb_dn2id: got id=0x4 > 4f41809b => mdb_entry_decode: > 4f41809b <= mdb_entry_decode > 4f41809b mdb_dn2entry("cn=managers,ou=group,dc=example,dc=com") > 4f41809b => mdb_dn2id("cn=managers,ou=group,dc=example,dc=com") > 4f41809b <= mdb_dn2id: got id=0x5 > 4f41809b => mdb_entry_decode: > 4f41809b <= mdb_entry_decode > 4f41809b => access_allowed: delete access to "ou=Group,dc=example,dc=com" > "children" requested > 4f41809b <= root access granted > 4f41809b => access_allowed: delete access granted by manage(=mwrscxd) > 4f41809b => access_allowed: delete access to > "cn=managers,ou=Group,dc=example,dc=com" "entry" requested > 4f41809b <= root access granted > 4f41809b => access_allowed: delete access granted by manage(=mwrscxd) > 4f41809b => mdb_dn2id_delete 0x5 > 4f41809b <= mdb_dn2id_delete 0x5: 0 > 4f41809b => index_entry_del( 5, "cn=managers,ou=Group,dc=example,dc=com" ) > 4f41809b mdb_idl_delete_keys: 5 [0096defd] > 4f41809b mdb_idl_delete_keys: 5 [8cc4ebff] > > Program received signal SIGSEGV, Segmentation fault. > [Switching to Thread 0x7fffb3e37700 (LWP 12696)] > 0x0000000000586b8b in lutil_str2bin (in=0x7fffb3e35e10, out=0x7fffb3e35e00, > ctx=0xbb8b70) at /home/matth/suum4x/ldap24/libraries/liblutil/utils.c:812 > 812 /home/matth/suum4x/ldap24/libraries/liblutil/utils.c: No such file or > directory. > > (gdb) thr apply all bt > > Thread 3 (Thread 0x7fffb3e37700 (LWP 12696)): > #0 0x0000000000586b8b in lutil_str2bin (in=0x7fffb3e35e10, > out=0x7fffb3e35e00, ctx=0xbb8b70) > at /home/matth/suum4x/ldap24/libraries/liblutil/utils.c:812 > #1 0x000000000048fe9f in integerVal2Key (in=0xbb9370, key=0xbb93c8, > tmp=0x7fffb3e35eb0, ctx=0xbb8b70) > at /home/matth/suum4x/ldap24/servers/slapd/schema_init.c:2545 > #2 0x000000000049029c in integerIndexer (use=163, flags=4, syntax=0x89e3f0, > mr=0x8a3c50, prefix=0x8b1158, values=0xbb9370, keysp=0x7fffb3e35f90, > ctx=0xbb8b70) at /home/matth/suum4x/ldap24/servers/slapd/schema_init.c:2634 > #3 0x000000000053d589 in indexer (op=0x7fffb3e36480, txn=0xccd410, > ai=0x91f8c0, ad=0x8b1280, atname=0x8b1158, vals=0xbb9370, id=5, opid=2, > mask=4) at /home/matth/suum4x/ldap24/servers/slapd/back-mdb/index.c:211 > #4 0x000000000053d96a in index_at_values (op=0x7fffb3e36480, txn=0xccd410, > ad=0x8b1280, type=0x8b10f0, tags=0x8b12a0, vals=0xbb9370, id=5, opid=2) > at /home/matth/suum4x/ldap24/servers/slapd/back-mdb/index.c:337 > #5 0x000000000053daf1 in mdb_index_values (op=0x7fffb3e36480, txn=0xccd410, > desc=0x8b1280, vals=0xbb9370, id=5, opid=2) > at /home/matth/suum4x/ldap24/servers/slapd/back-mdb/index.c:386 > #6 0x000000000053dfb9 in mdb_index_entry (op=0x7fffb3e36480, txn=0xccd410, > opid=2, e=0xbb9178) > at /home/matth/suum4x/ldap24/servers/slapd/back-mdb/index.c:558 > #7 0x00000000005324e1 in mdb_delete (op=0x7fffb3e36480, rs=0x7fffb3e36340) > at /home/matth/suum4x/ldap24/servers/slapd/back-mdb/delete.c:348 > #8 0x0000000000554935 in remove_query_data (op=0x7fffb3e36480, > query_uuid=0xcc3090) > at /home/matth/suum4x/ldap24/servers/slapd/overlays/pcache.c:1838 > #9 0x0000000000559ce4 in consistency_check (ctx=0x7fffb3e36b90, arg=0x995050) > at /home/matth/suum4x/ldap24/servers/slapd/overlays/pcache.c:3579 > #10 0x00007ffff7b8fb32 in ldap_int_thread_pool_wrapper (xpool=0x8b3ae0) > at /home/matth/suum4x/ldap24/libraries/libldap_r/tpool.c:688 > #11 0x00007ffff66f98ba in start_thread () from /lib/libpthread.so.0 > #12 0x00007ffff646102d in clone () from /lib/libc.so.6 > #13 0x0000000000000000 in ?? () > > Thread 2 (Thread 0x7fffb4638700 (LWP 12695)): > #0 0x00007ffff6461623 in epoll_wait () from /lib/libc.so.6 > #1 0x000000000043e986 in slapd_daemon_task (ptr=0x7fffffffe528) > at /home/matth/suum4x/ldap24/servers/slapd/daemon.c:2539 > #2 0x00007ffff66f98ba in start_thread () from /lib/libpthread.so.0 > #3 0x00007ffff646102d in clone () from /lib/libc.so.6 > #4 0x0000000000000000 in ?? () > > ---Type <return> to continue, or q <return> to quit--- > Thread 1 (Thread 0x7ffff7fef700 (LWP 12692)): > #0 0x00007ffff66fabe5 in pthread_join () from /lib/libpthread.so.0 > #1 0x00007ffff7b91040 in ldap_pvt_thread_join (thread=140736219809536, > thread_return=0x0) > at /home/matth/suum4x/ldap24/libraries/libldap_r/thr_posix.c:197 > #2 0x000000000043fab8 in slapd_daemon () > at /home/matth/suum4x/ldap24/servers/slapd/daemon.c:2930 > #3 0x000000000041d43b in main (argc=3, argv=0x7fffffffe778) > at /home/matth/suum4x/ldap24/servers/slapd/main.c:1011 > (gdb) > > ## > ## SUUM v4 slapd Configuration File. Adjust settings as needed for your > ## deployment. > ## > include "/opt/suum/etc/schema/core.schema" > include "/opt/suum/etc/schema/cosine.schema" > include "/opt/suum/etc/schema/inetorgperson.schema" > include "/opt/suum/etc/schema/misc.schema" > include "/opt/suum/etc/schema/rfc2307bis.schema" > include "/opt/suum/etc/schema/ldapns.schema" > > #TLSCACertificateFile "/opt/suum/ssl/cacert.pem" > > pidfile "/var/symas/suum/slapd.pid" > argsfile "/var/symas/suum/slapd.args" > > modulepath "/opt/suum/lib64/modules" > moduleload nssov.la > > access to dn="" by * read > access to * > by self write > by users read > by anonymous auth > > database ldap > suffix "dc=example,dc=com" > rootdn "dc=example,dc=com" > uri ldap://xxxxxxx > idassert-bind bindmethod=simple > binddn=cn=proxy,ou=restricted,dc=example,dc=com > credentials=secret > > overlay nssov > nssov-pam userhost userservice usergroup > > nssov-ssd passwd ldap:///ou=People,dc=example,dc=com??one > nssov-ssd shadow ldap:///ou=People,dc=example,dc=com??one > nssov-ssd group ldap:///ou=Group,dc=example,dc=com??one > nssov-ssd hosts ldap:///ou=Hosts,dc=example,dc=com??one > nssov-ssd services ldap:///ou=Services,dc=example,dc=com??one > nssov-ssd networks ldap:///ou=Networks,dc=example,dc=com??one > nssov-ssd protocols ldap:///ou=Protocols,dc=example,dc=com??one > nssov-ssd rpc ldap:///ou=Rpc,dc=example,dc=com??one > nssov-ssd ethers ldap:///ou=Hosts,dc=example,dc=com??one > nssov-ssd netgroup ldap:///ou=Netgroup,dc=example,dc=com??one > nssov-ssd aliases ldap:///ou=Aliases,dc=example,dc=com??one > > overlay pcache > response-callback head > > pcache mdb 500000 11 1000 300 > > pcachePersist FALSE > > pcacheAttrset 0 cn uid uidNumber gidNumber > homeDirectory userPassword loginShell > gecos description objectClass > pcacheAttrset 1 uid userPassword shadowLastChange shadowMin > shadowMax shadowWarning shadowInactive > shadowExpire shadowFlag description objectClass > pcacheAttrset 2 cn gidNumber userPassword memberUid > uniqueMember description objectClass > pcacheAttrset 3 cn ipHostNumber l description > manager objectClass > pcacheAttrset 4 cn ipServicePort ipServiceProtocol description > objectClass > pcacheAttrset 5 cn ipNetworkNumber ipNetmaskNumber l > description manager objectClass > pcacheAttrset 6 cn ipProtocolNumber description objectClass > > pcacheAttrset 7 cn oncRpcNumber description objectClass > > pcacheAttrset 8 cn macAddress objectClass > > pcacheAttrset 9 cn nisNetgroupTriple memberNisNetgroup description > objectClass > pcacheAttrset 10 cn rfc822MailMember objectClass > > pcacheTemplate > (&(objectClass=)(uid=)) 0 60 > > pcacheTemplate > (&(objectClass=)(uidNumber=)) 0 60 > > pcacheTemplate > (objectClass=) 0 60 > > pcacheTemplate > (&(objectClass=)(uid=)) 1 60 > > pcacheTemplate > (objectClass=) 2 60 > > pcacheTemplate > (&(objectClass=)(cn=)) 2 60 > > pcacheTemplate > (&(objectClass=)(gidNumber=)) 2 60 > > pcacheTemplate > (&(objectClass=)(|(memberUid=)(uniqueMember=)) 2 60 > > pcacheTemplate > (objectClass=) 3 60 > > pcacheTemplate > (&(objectClass=)(cn=)) 3 60 > > pcacheTemplate > (&(objectClass=)(ipHostNumber=)) 3 60 > > pcacheTemplate > (objectClass=) 4 60 > > pcacheTemplate > (&(objectClass=)(cn=)) 4 60 > > pcacheTemplate > (&(objectClass=)(ipServicePort=)) 4 60 > > pcacheTemplate > (&(objectClass=)(cn=)(ipServiceProtocol=)) 4 60 > > pcacheTemplate > (&(objectClass=)(ipServicePort=)(ipServiceProtocol=)) 4 60 > > pcacheTemplate > (objectClass=) 5 60 > > pcacheTemplate > (&(objectClass=)(cn=)) 5 60 > > pcacheTemplate > (&(objectClass=)(ipNetworkNumber=)) 5 60 > > pcacheTemplate > (objectClass=) 6 60 > > pcacheTemplate > (&(objectClass=)(cn=)) 6 60 > > pcacheTemplate > (&(objectClass=)(ipProtocolNumber=)) 6 60 > > pcacheTemplate > (objectClass=) 7 60 > > pcacheTemplate > (&(objectClass=)(cn=)) 7 60 > > pcacheTemplate > (&(objectClass=)(oncRpcNumber=)) 7 60 > > pcacheTemplate > (&(objectClass=)(cn=)) 8 60 > > pcacheTemplate > (&(objectClass=)(macAddress=)) 8 60 > > pcacheTemplate > (&(objectClass=)(cn=)) 9 60 > > pcacheTemplate > (&(objectClass=)(cn=)) 10 60 > > directory "/var/symas/suum/cache" > > maxsize 1073741824 > > index default eq > index objectClass > index cn,uid,uidNumber,gidNumber > index memberUid,uniqueMember > index ipHostNumber,ipServicePort,ipServiceProtocol > index ipNetworkNumber,ipProtocolNumber > index oncRpcNumber,macAddress > > # Monitor database > database monitor >

1 0

(ITS#7175) Segv during cache entry delete pcache+back-mdb
by mhardin＠symas.com 19 Feb '12

19 Feb '12

Full_Name: Matthew Hardin Version: 2.4.29 OS: Linux (Debian 6) URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (170.215.93.127) During a cache delete operation (TTL expired) a segv is raised. Log and backtrace follow: 4f41809b DELETING ENTRY TEMPLATE=7d824524-ef99-1030-9d9b-fbe800313ae3 4f41809b ==> mdb_delete: cn=managers,ou=group,dc=example,dc=com 4f41809b slap_queue_csn: queing 0x7fffb3e36150 20120219230707.188204Z#000000#000#000000 4f41809b mdb_dn2entry("ou=group,dc=example,dc=com") 4f41809b => mdb_dn2id("ou=group,dc=example,dc=com") 4f41809b <= mdb_dn2id: got id=0x4 4f41809b => mdb_entry_decode: 4f41809b <= mdb_entry_decode 4f41809b mdb_dn2entry("cn=managers,ou=group,dc=example,dc=com") 4f41809b => mdb_dn2id("cn=managers,ou=group,dc=example,dc=com") 4f41809b <= mdb_dn2id: got id=0x5 4f41809b => mdb_entry_decode: 4f41809b <= mdb_entry_decode 4f41809b => access_allowed: delete access to "ou=Group,dc=example,dc=com" "children" requested 4f41809b <= root access granted 4f41809b => access_allowed: delete access granted by manage(=mwrscxd) 4f41809b => access_allowed: delete access to "cn=managers,ou=Group,dc=example,dc=com" "entry" requested 4f41809b <= root access granted 4f41809b => access_allowed: delete access granted by manage(=mwrscxd) 4f41809b => mdb_dn2id_delete 0x5 4f41809b <= mdb_dn2id_delete 0x5: 0 4f41809b => index_entry_del( 5, "cn=managers,ou=Group,dc=example,dc=com" ) 4f41809b mdb_idl_delete_keys: 5 [0096defd] 4f41809b mdb_idl_delete_keys: 5 [8cc4ebff] Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x7fffb3e37700 (LWP 12696)] 0x0000000000586b8b in lutil_str2bin (in=0x7fffb3e35e10, out=0x7fffb3e35e00, ctx=0xbb8b70) at /home/matth/suum4x/ldap24/libraries/liblutil/utils.c:812 812 /home/matth/suum4x/ldap24/libraries/liblutil/utils.c: No such file or directory. (gdb) thr apply all bt Thread 3 (Thread 0x7fffb3e37700 (LWP 12696)): #0 0x0000000000586b8b in lutil_str2bin (in=0x7fffb3e35e10, out=0x7fffb3e35e00, ctx=0xbb8b70) at /home/matth/suum4x/ldap24/libraries/liblutil/utils.c:812 #1 0x000000000048fe9f in integerVal2Key (in=0xbb9370, key=0xbb93c8, tmp=0x7fffb3e35eb0, ctx=0xbb8b70) at /home/matth/suum4x/ldap24/servers/slapd/schema_init.c:2545 #2 0x000000000049029c in integerIndexer (use=163, flags=4, syntax=0x89e3f0, mr=0x8a3c50, prefix=0x8b1158, values=0xbb9370, keysp=0x7fffb3e35f90, ctx=0xbb8b70) at /home/matth/suum4x/ldap24/servers/slapd/schema_init.c:2634 #3 0x000000000053d589 in indexer (op=0x7fffb3e36480, txn=0xccd410, ai=0x91f8c0, ad=0x8b1280, atname=0x8b1158, vals=0xbb9370, id=5, opid=2, mask=4) at /home/matth/suum4x/ldap24/servers/slapd/back-mdb/index.c:211 #4 0x000000000053d96a in index_at_values (op=0x7fffb3e36480, txn=0xccd410, ad=0x8b1280, type=0x8b10f0, tags=0x8b12a0, vals=0xbb9370, id=5, opid=2) at /home/matth/suum4x/ldap24/servers/slapd/back-mdb/index.c:337 #5 0x000000000053daf1 in mdb_index_values (op=0x7fffb3e36480, txn=0xccd410, desc=0x8b1280, vals=0xbb9370, id=5, opid=2) at /home/matth/suum4x/ldap24/servers/slapd/back-mdb/index.c:386 #6 0x000000000053dfb9 in mdb_index_entry (op=0x7fffb3e36480, txn=0xccd410, opid=2, e=0xbb9178) at /home/matth/suum4x/ldap24/servers/slapd/back-mdb/index.c:558 #7 0x00000000005324e1 in mdb_delete (op=0x7fffb3e36480, rs=0x7fffb3e36340) at /home/matth/suum4x/ldap24/servers/slapd/back-mdb/delete.c:348 #8 0x0000000000554935 in remove_query_data (op=0x7fffb3e36480, query_uuid=0xcc3090) at /home/matth/suum4x/ldap24/servers/slapd/overlays/pcache.c:1838 #9 0x0000000000559ce4 in consistency_check (ctx=0x7fffb3e36b90, arg=0x995050) at /home/matth/suum4x/ldap24/servers/slapd/overlays/pcache.c:3579 #10 0x00007ffff7b8fb32 in ldap_int_thread_pool_wrapper (xpool=0x8b3ae0) at /home/matth/suum4x/ldap24/libraries/libldap_r/tpool.c:688 #11 0x00007ffff66f98ba in start_thread () from /lib/libpthread.so.0 #12 0x00007ffff646102d in clone () from /lib/libc.so.6 #13 0x0000000000000000 in ?? () Thread 2 (Thread 0x7fffb4638700 (LWP 12695)): #0 0x00007ffff6461623 in epoll_wait () from /lib/libc.so.6 #1 0x000000000043e986 in slapd_daemon_task (ptr=0x7fffffffe528) at /home/matth/suum4x/ldap24/servers/slapd/daemon.c:2539 #2 0x00007ffff66f98ba in start_thread () from /lib/libpthread.so.0 #3 0x00007ffff646102d in clone () from /lib/libc.so.6 #4 0x0000000000000000 in ?? () ---Type <return> to continue, or q <return> to quit--- Thread 1 (Thread 0x7ffff7fef700 (LWP 12692)): #0 0x00007ffff66fabe5 in pthread_join () from /lib/libpthread.so.0 #1 0x00007ffff7b91040 in ldap_pvt_thread_join (thread=140736219809536, thread_return=0x0) at /home/matth/suum4x/ldap24/libraries/libldap_r/thr_posix.c:197 #2 0x000000000043fab8 in slapd_daemon () at /home/matth/suum4x/ldap24/servers/slapd/daemon.c:2930 #3 0x000000000041d43b in main (argc=3, argv=0x7fffffffe778) at /home/matth/suum4x/ldap24/servers/slapd/main.c:1011 (gdb) ## ## SUUM v4 slapd Configuration File. Adjust settings as needed for your ## deployment. ## include "/opt/suum/etc/schema/core.schema" include "/opt/suum/etc/schema/cosine.schema" include "/opt/suum/etc/schema/inetorgperson.schema" include "/opt/suum/etc/schema/misc.schema" include "/opt/suum/etc/schema/rfc2307bis.schema" include "/opt/suum/etc/schema/ldapns.schema" #TLSCACertificateFile "/opt/suum/ssl/cacert.pem" pidfile "/var/symas/suum/slapd.pid" argsfile "/var/symas/suum/slapd.args" modulepath "/opt/suum/lib64/modules" moduleload nssov.la access to dn="" by * read access to * by self write by users read by anonymous auth database ldap suffix "dc=example,dc=com" rootdn "dc=example,dc=com" uri ldap://xxxxxxx idassert-bind bindmethod=simple binddn=cn=proxy,ou=restricted,dc=example,dc=com credentials=secret overlay nssov nssov-pam userhost userservice usergroup nssov-ssd passwd ldap:///ou=People,dc=example,dc=com??one nssov-ssd shadow ldap:///ou=People,dc=example,dc=com??one nssov-ssd group ldap:///ou=Group,dc=example,dc=com??one nssov-ssd hosts ldap:///ou=Hosts,dc=example,dc=com??one nssov-ssd services ldap:///ou=Services,dc=example,dc=com??one nssov-ssd networks ldap:///ou=Networks,dc=example,dc=com??one nssov-ssd protocols ldap:///ou=Protocols,dc=example,dc=com??one nssov-ssd rpc ldap:///ou=Rpc,dc=example,dc=com??one nssov-ssd ethers ldap:///ou=Hosts,dc=example,dc=com??one nssov-ssd netgroup ldap:///ou=Netgroup,dc=example,dc=com??one nssov-ssd aliases ldap:///ou=Aliases,dc=example,dc=com??one overlay pcache response-callback head pcache mdb 500000 11 1000 300 pcachePersist FALSE pcacheAttrset 0 cn uid uidNumber gidNumber homeDirectory userPassword loginShell gecos description objectClass pcacheAttrset 1 uid userPassword shadowLastChange shadowMin shadowMax shadowWarning shadowInactive shadowExpire shadowFlag description objectClass pcacheAttrset 2 cn gidNumber userPassword memberUid uniqueMember description objectClass pcacheAttrset 3 cn ipHostNumber l description manager objectClass pcacheAttrset 4 cn ipServicePort ipServiceProtocol description objectClass pcacheAttrset 5 cn ipNetworkNumber ipNetmaskNumber l description manager objectClass pcacheAttrset 6 cn ipProtocolNumber description objectClass pcacheAttrset 7 cn oncRpcNumber description objectClass pcacheAttrset 8 cn macAddress objectClass pcacheAttrset 9 cn nisNetgroupTriple memberNisNetgroup description objectClass pcacheAttrset 10 cn rfc822MailMember objectClass pcacheTemplate (&(objectClass=)(uid=)) 0 60 pcacheTemplate (&(objectClass=)(uidNumber=)) 0 60 pcacheTemplate (objectClass=) 0 60 pcacheTemplate (&(objectClass=)(uid=)) 1 60 pcacheTemplate (objectClass=) 2 60 pcacheTemplate (&(objectClass=)(cn=)) 2 60 pcacheTemplate (&(objectClass=)(gidNumber=)) 2 60 pcacheTemplate (&(objectClass=)(|(memberUid=)(uniqueMember=)) 2 60 pcacheTemplate (objectClass=) 3 60 pcacheTemplate (&(objectClass=)(cn=)) 3 60 pcacheTemplate (&(objectClass=)(ipHostNumber=)) 3 60 pcacheTemplate (objectClass=) 4 60 pcacheTemplate (&(objectClass=)(cn=)) 4 60 pcacheTemplate (&(objectClass=)(ipServicePort=)) 4 60 pcacheTemplate (&(objectClass=)(cn=)(ipServiceProtocol=)) 4 60 pcacheTemplate (&(objectClass=)(ipServicePort=)(ipServiceProtocol=)) 4 60 pcacheTemplate (objectClass=) 5 60 pcacheTemplate (&(objectClass=)(cn=)) 5 60 pcacheTemplate (&(objectClass=)(ipNetworkNumber=)) 5 60 pcacheTemplate (objectClass=) 6 60 pcacheTemplate (&(objectClass=)(cn=)) 6 60 pcacheTemplate (&(objectClass=)(ipProtocolNumber=)) 6 60 pcacheTemplate (objectClass=) 7 60 pcacheTemplate (&(objectClass=)(cn=)) 7 60 pcacheTemplate (&(objectClass=)(oncRpcNumber=)) 7 60 pcacheTemplate (&(objectClass=)(cn=)) 8 60 pcacheTemplate (&(objectClass=)(macAddress=)) 8 60 pcacheTemplate (&(objectClass=)(cn=)) 9 60 pcacheTemplate (&(objectClass=)(cn=)) 10 60 directory "/var/symas/suum/cache" maxsize 1073741824 index default eq index objectClass index cn,uid,uidNumber,gidNumber index memberUid,uniqueMember index ipHostNumber,ipServicePort,ipServiceProtocol index ipNetworkNumber,ipProtocolNumber index oncRpcNumber,macAddress # Monitor database database monitor

1 0

(ITS#7174) back-mdb segfaults when deleting accesslog data
by quanah＠OpenLDAP.org 19 Feb '12

19 Feb '12

Full_Name: Quanah Gibson-Mount Version: 2.4.29 OS: Linux 2.6 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (75.108.184.39) If you shut down slapd long enough so that data in accesslog is set to expire, then start up slapd, slapd will segfault: 4f41783d => access_allowed: delete access to "cn=accesslog" "children" requested 4f41783d <= root access granted 4f41783d => access_allowed: delete access granted by manage(=mwrscxd) 4f41783d => access_allowed: delete access to "reqStart=20120217204307.000031Z,cn=accesslog" "entry" requested 4f41783d <= root access granted 4f41783d => access_allowed: delete access granted by manage(=mwrscxd) 4f41783d => mdb_dn2id_delete 0x2 4f41783d <= mdb_dn2id_delete 0x2: 0 4f41783d => index_entry_del( 2, "reqStart=20120217204307.000031Z,cn=accesslog" ) 4f41783d mdb_idl_delete_keys: 2 [66ec5701] 4f41783d mdb_idl_delete_keys: 2 4f41783d mdb_idl_delete_keys: 2 Segmentation fault Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x7fd7d8f0f700 (LWP 22524)] 0x00000000004f5084 in lutil_str2bin (in=0x7fd7d8f0db50, out=0x7fd7d8f0db40, ctx=0x937190) at utils.c:812 812 utils.c: No such file or directory. in utils.c Thread 6 (Thread 0x7fd7d7f0d700 (LWP 22526)): #0 0x00007ffff71a485c in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 #1 0x00007ffff7b8e29e in ldap_pvt_thread_cond_wait (cond=0x7d6760, mutex=0x7d6738) at thr_posix.c:277 #2 0x00007ffff7b8cc02 in ldap_int_thread_pool_wrapper (xpool=0x7d6730) at tpool.c:675 #3 0x00007ffff719f9ca in start_thread () from /lib/libpthread.so.0 #4 0x00007ffff607c70d in clone () from /lib/libc.so.6 #5 0x0000000000000000 in ?? () Thread 5 (Thread 0x7fd7d870e700 (LWP 22525)): #0 0x00007ffff71a485c in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 #1 0x00007ffff7b8e29e in ldap_pvt_thread_cond_wait (cond=0x7d6760, mutex=0x7d6738) at thr_posix.c:277 #2 0x00007ffff7b8cc02 in ldap_int_thread_pool_wrapper (xpool=0x7d6730) at tpool.c:675 #3 0x00007ffff719f9ca in start_thread () from /lib/libpthread.so.0 #4 0x00007ffff607c70d in clone () from /lib/libc.so.6 #5 0x0000000000000000 in ?? () Thread 4 (Thread 0x7fd7d8f0f700 (LWP 22524)): #0 0x00000000004f5084 in lutil_str2bin (in=0x7fd7d8f0db50, out=0x7fd7d8f0db40, ctx=0x937190) at utils.c:812 #1 0x000000000048b637 in integerVal2Key (in=0xff76f0, key=0xff78c0, tmp=0x7fd7d8f0dc00, ctx=0x937190) at schema_init.c:2545 #2 0x000000000048ba97 in integerIndexer (use=163, flags=4, syntax=0x7c1040, mr=0x7c68a0, prefix=0x828a08, values=0xff76f0, keysp=0x7fd7d8f0dd00, ctx=0x937190) at schema_init.c:2634 #3 0x00007ffff104bead in indexer (op=0x7fd7d8f0e460, txn=0x93ea40, ai=0x8c6140, ad=0x828b30, atname=0x828a08, vals=0xff76f0, id=2, opid=2, mask=4) at index.c:211 #4 0x00007ffff104c28b in index_at_values (op=0x7fd7d8f0e460, txn=0x93ea40, ad=0x828b30, type=0x8289a0, tags=0x828b50, vals=0xff76f0, id=2, opid=2) at index.c:337 #5 0x00007ffff104c40f in mdb_index_values (op=0x7fd7d8f0e460, txn=0x93ea40, desc=0x828b30, vals=0xff76f0, id=2, opid=2) at index.c:386 #6 0x00007ffff104c8d7 in mdb_index_entry (op=0x7fd7d8f0e460, txn=0x93ea40, opid=2, e=0xff72a0) at index.c:558 #7 0x00007ffff10403d6 in mdb_delete (op=0x7fd7d8f0e460, rs=0x7fd7d8f0e2d0) at delete.c:348 #8 0x00000000004d4920 in overlay_op_walk (op=0x7fd7d8f0e460, rs=0x7fd7d8f0e2d0, which=op_delete, oi=0x8a3310, on=0x0) at backover.c:671 #9 0x00000000004d4b5e in over_op_func (op=0x7fd7d8f0e460, rs=0x7fd7d8f0e2d0, which=op_delete) at backover.c:723 #10 0x00000000004d4d47 in over_op_delete (op=0x7fd7d8f0e460, rs=0x7fd7d8f0e2d0) at backover.c:780 #11 0x00007ffff09eef81 in accesslog_purge (ctx=0x7fd7d8f0eb70, arg=0x8a0fd0) at accesslog.c:689 #12 0x00007ffff7b8cca9 in ldap_int_thread_pool_wrapper (xpool=0x7d6730) at tpool.c:688 #13 0x00007ffff719f9ca in start_thread () from /lib/libpthread.so.0 #14 0x00007ffff607c70d in clone () from /lib/libc.so.6 #15 0x0000000000000000 in ?? () Thread 3 (Thread 0x7fd7d9710700 (LWP 22523)): #0 0x00007ffff71a485c in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 #1 0x00007ffff7b8e29e in ldap_pvt_thread_cond_wait (cond=0x7d6760, mutex=0x7d6738) at thr_posix.c:277 #2 0x00007ffff7b8cc02 in ldap_int_thread_pool_wrapper (xpool=0x7d6730) at tpool.c:675 #3 0x00007ffff719f9ca in start_thread () from /lib/libpthread.so.0 #4 0x00007ffff607c70d in clone () from /lib/libc.so.6 #5 0x0000000000000000 in ?? () Thread 2 (Thread 0x7fd7d9f11700 (LWP 22522)): #0 0x00007ffff607cd03 in epoll_wait () from /lib/libc.so.6 #1 0x00000000004394b3 in slapd_daemon_task (ptr=0x7fffffffe47c) at daemon.c:2539 #2 0x00007ffff719f9ca in start_thread () from /lib/libpthread.so.0 #3 0x00007ffff607c70d in clone () from /lib/libc.so.6 #4 0x0000000000000000 in ?? () Thread 1 (Thread 0x7ffff7fef700 (LWP 22519)): #0 0x00007ffff71a103d in pthread_join () from /lib/libpthread.so.0 #1 0x00007ffff7b8e1df in ldap_pvt_thread_join (thread=140565051152128, thread_return=0x0) at thr_posix.c:197 #2 0x000000000043a6c5 in slapd_daemon () at daemon.c:2930 #3 0x0000000000416e7f in main (argc=11, argv=0x7fffffffe688) at main.c:1012 Thread 4 bt full: #0 0x00000000004f5084 in lutil_str2bin (in=0x7fd7d8f0db50, out=0x7fd7d8f0db40, ctx=0x937190) at utils.c:812 tmpbuf = "\352\037\026\332\353\177\000\000\b\000\000\000\000\000\000\000 \333\360\330\327\177\000\000\000\000\200\000\000\000\000\000\300\371\360\330\327\177\000\000-\n\006\361\377\177\000\000\000\000\000\000\000\000\000\000?\224\000\000\000\000" tmp = 0x7fd7d8f0dac0 "\352\037\026\332\353\177" num = {buf = 0x7fd7d8f0dc30 "\220\334\360\330\327\177", bufsiz = 64, beg = 63, len = 0} neg = 0 l = 0 pin = 0x7febda12bebc "0" pout = 0x7fd7d8f0dc30 "\220\334\360\330\327\177" ctmp = 0 '\000' end = 0x7ffff105c0c2 "\211E\354\203}", <incomplete sequence \354> i = -167659543 chunk = 1 len = 1 rc = 0 hex = 0 #1 0x000000000048b637 in integerVal2Key (in=0xff76f0, key=0xff78c0, tmp=0x7fd7d8f0dc00, ctx=0x937190) at schema_init.c:2545 k = 11 chop = 0 signmask = 4294967168 lenbuf = "\320\333\360\330\327\177\000\000\220q" lenp = 0x43800000420 <Address 0x43800000420 out of bounds> neg = 0 '\000' val = {bv_len = 1, bv_val = 0x7febda12bebc "0"} itmp = {bv_len = 64, bv_val = 0x7fd7d8f0dc30 "\220\334\360\330\327\177"} __PRETTY_FUNCTION__ = "integerVal2Key" #2 0x000000000048ba97 in integerIndexer (use=163, flags=4, syntax=0x7c1040, mr=0x7c68a0, prefix=0x828a08, values=0xff76f0, keysp=0x7fd7d8f0dd00, ctx=0x937190) at schema_init.c:2634 ibuf = "\220\334\360\330\327\177\000\000\275\022\006\361\377\177\000\000`\334\360\330\327\177\000\000\370\334\360\330\327\177\000\000\220q\223\000\t\000\000\000@\352\223\000\000\000\000\000OY\005\361\377\177\000\000x\003\000\000\000\000\000" itmp = {bv_len = 64, bv_val = 0x7fd7d8f0dc30 "\220\334\360\330\327\177"} keys = 0xff78c0 vlen = 1 i = 0 rc = 9669312 maxstrlen = 18 __PRETTY_FUNCTION__ = "integerIndexer" #3 0x00007ffff104bead in indexer (op=0x7fd7d8f0e460, txn=0x93ea40, ai=0x8c6140, ad=0x828b30, atname=0x828a08, vals=0xff76f0, id=2, opid=2, mask=4) at index.c:211 rc = 0 i = -136134640 keys = 0x828b30 mc = 0x938ac0 keyfunc = 0x7ffff105594f <mdb_idl_delete_keys> err = 0x7ffff1068eea "c_open" __PRETTY_FUNCTION__ = "indexer" #4 0x00007ffff104c28b in index_at_values (op=0x7fd7d8f0e460, txn=0x93ea40, ad=0x828b30, type=0x8289a0, tags=0x828b50, vals=0xff76f0, id=2, opid=2) at index.c:337 rc = 0 mask = 4 ixop = 2 ai = 0x8c6140 #5 0x00007ffff104c40f in mdb_index_values (op=0x7fd7d8f0e460, txn=0x93ea40, desc=0x828b30, vals=0xff76f0, id=2, opid=2) at index.c:386 rc = 0 #6 0x00007ffff104c8d7 in mdb_index_entry (op=0x7fd7d8f0e460, txn=0x93ea40, opid=2, e=0xff72a0) at index.c:558 rc = 0 ap = 0xff7430 #7 0x00007ffff10403d6 in mdb_delete (op=0x7fd7d8f0e460, rs=0x7fd7d8f0e2d0) at delete.c:348 mdb = 0x7ffff7e2c010 pdn = {bv_len = 12, bv_val = 0x939c90 "cn=accesslog"} e = 0xff72a0 p = 0xff7050 manageDSAit = 0 children = 0x7d1e30 entry = 0x7d1b90 txn = 0x93ea40 mc = 0x938ac0 opinfo = {moi_oe = {oe_next = {sle_next = 0x0}, oe_key = 0x7ffff7e2c010}, moi_txn = 0x93ea40, moi_ref = 1, moi_flag = 0 '\000'} moi = 0x7fd7d8f0def0 preread_ctrl = 0x0 ctrls = {0x0, 0xfffffffffffffff9, 0x7fd7d8f0df30, 0x800000, 0x7fd7d8f0f9c0, 0x4} num_ctrls = 0 parent_is_glue = 0 parent_is_leaf = 0 __PRETTY_FUNCTION__ = "mdb_delete" #8 0x00000000004d4920 in overlay_op_walk (op=0x7fd7d8f0e460, rs=0x7fd7d8f0e2d0, which=op_delete, oi=0x8a3310, on=0x0) at backover.c:671 func = 0x7ffff126ed18 rc = 32768 #9 0x00000000004d4b5e in over_op_func (op=0x7fd7d8f0e460, rs=0x7fd7d8f0e2d0, which=op_delete) at backover.c:723 oi = 0x8a3310 on = 0x8be110 be = 0x8b99e0 db = {bd_info = 0x7ffff126ecc0, bd_self = 0x8b99e0, be_ctrls = "\000\001\001\001\000\001\000\000\001\000\000\001\001\000\001\000\000\001", '\000' <repeats 14 times>, "\001", be_flags = 2312, 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 = 0x8ac330, be_nsuffix = 0x8aaae0, be_schemadn = {bv_len = 0, bv_val = 0x0}, be_schemandn = { bv_len = 0, bv_val = 0x0}, be_rootdn = {bv_len = 9, bv_val = 0x8aa2e0 "cn=config"}, be_rootndn = {bv_len = 9, bv_val = 0x8a9f60 "cn=config"}, be_rootpw = {bv_len = 0, bv_val = 0x0}, be_max_deref_depth = 15, be_def_limit = {lms_t_soft = -1, 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 = 0x8aabc0, 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 = 0x91e410, 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 = 0x7ffff126eac0, be_private = 0x7ffff7e2c010, be_next = {stqe_next = 0x8baee0}} cb = {sc_next = 0x7ffff0bf8c60, sc_response = 0x4d3658 <over_back_response>, sc_cleanup = 0, sc_private = 0x8a3310} sc = 0x825b58 rc = 32768 __PRETTY_FUNCTION__ = "over_op_func" #10 0x00000000004d4d47 in over_op_delete (op=0x7fd7d8f0e460, rs=0x7fd7d8f0e2d0) at backover.c:780 No locals. #11 0x00007ffff09eef81 in accesslog_purge (ctx=0x7fd7d8f0eb70, arg=0x8a0fd0) at accesslog.c:689 i = 0 rtask = 0x8a0fd0 li = 0x8a0ec0 conn = {c_struct_state = SLAP_C_UNINITIALIZED, c_conn_state = SLAP_C_INVALID, c_conn_idx = -1, c_sd = 0, c_close_reason = 0x0, c_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}, c_sb = 0x0, c_starttime = 0, c_activitytime = 0, c_connid = 18446744073709551615, c_peer_domain = {bv_len = 0, bv_val = 0x4fafb0 ""}, c_peer_name = {bv_len = 0, bv_val = 0x4fafb0 ""}, c_listener = 0x502e20, c_sasl_bind_mech = {bv_len = 0, bv_val = 0x0}, c_sasl_dn = {bv_len = 0, bv_val = 0x0}, c_sasl_authz_dn = {bv_len = 0, bv_val = 0x0}, c_authz_backend = 0x0, c_authz_cookie = 0x0, c_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}, c_protocol = 0, c_ops = {stqh_first = 0x0, stqh_last = 0x0}, c_pending_ops = {stqh_first = 0x0, stqh_last = 0x0}, c_write1_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}, c_write1_cv = {__data = {__lock = 0, __futex = 0, __total_seq = 0, __wakeup_seq = 0, __woken_seq = 0, __mutex = 0x0, __nwaiters = 0, __broadcast_seq = 0}, __size = '\000' <repeats 47 times>, __align = 0}, c_write2_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}, c_write2_cv = {__data = {__lock = 0, __futex = 0, __total_seq = 0, __wakeup_seq = 0, __woken_seq = 0, __mutex = 0x0, __nwaiters = 0, __broadcast_seq = 0}, __size = '\000' <repeats 47 times>, __align = 0}, c_currentber = 0x0, c_writers = 0, c_writing = 0 '\000', c_sasl_bind_in_progress = 0 '\000', c_writewaiter = 0 '\000', c_is_tls = 0 '\000', c_needs_tls_accept = 0 '\000', c_sasl_layers = 0 '\000', c_sasl_done = 0 '\000', c_sasl_authctx = 0x0, c_sasl_sockctx = 0x0, c_sasl_extra = 0x0, c_sasl_bindop = 0x0, c_pagedresults_state = {ps_be = 0x0, ps_size = 0, ps_count = 0, ps_cookie = 0, ps_cookieval = {bv_len = 0, bv_val = 0x0}}, c_n_ops_received = 0, c_n_ops_executing = 0, c_n_ops_pending = 0, c_n_ops_completed = 0, c_n_get = 0, c_n_read = 0, c_n_write = 0, c_extensions = 0x0, c_clientfunc = 0, c_clientarg = 0x0, c_send_ldap_result = 0x454925 <slap_send_ldap_result>, c_send_search_entry = 0x45562d <slap_send_search_entry>, c_send_search_reference = 0x457b53 <slap_send_search_reference>, c_send_ldap_extended = 0x45518c <slap_send_ldap_extended>, c_send_ldap_intermediate = 0x45540a <slap_send_ldap_intermediate>} opbuf = {ob_op = {o_hdr = 0x7fd7d8f0e5d0, o_tag = 74, o_time = 1329690902, o_tincr = 4, o_bd = 0x7fd7d8f0e0e0, o_req_dn = {bv_len = 44, bv_val = 0x929b00 "reqStart=20120217204307.000031Z,cn=accesslog"}, o_req_ndn = {bv_len = 44, bv_val = 0x939c70 "reqStart=20120217204307.000031Z,cn=accesslog"}, o_request = { oq_add = {rs_modlist = 0x1, rs_e = 0xffffffffffffffff}, oq_bind = {rb_method = 1, rb_cred = {bv_len = 18446744073709551615, bv_val = 0x0}, rb_edn = {bv_len = 1, bv_val = 0x75ed60 "\003"}, rb_ssf = 3639665680, rb_mech = {bv_len = 27, bv_val = 0xff6fa8 "\220\340\360\330\327\177"}}, oq_compare = {rs_ava = 0x1}, oq_modify = { rs_mods = {rs_modlist = 0x1, rs_no_opattrs = -1 '\377'}, rs_increment = 0}, oq_modrdn = {rs_mods = {rs_modlist = 0x1, rs_no_opattrs = -1 '\377'}, rs_deleteoldrdn = 0, rs_newrdn = {bv_len = 1, bv_val = 0x75ed60 "\003"}, rs_nnewrdn = {bv_len = 140565034361872, bv_val = 0x1b <Address 0x1b out of bounds>}, rs_newSup = 0xff6fa8, rs_nnewSup = 0x0}, oq_search = {rs_scope = 1, rs_deref = 0, rs_slimit = -1, rs_tlimit = -1, rs_limit = 0x0, rs_attrsonly = 1, rs_attrs = 0x75ed60, rs_filter = 0x7fd7d8f0e410, rs_filterstr = {bv_len = 27, bv_val = 0xff6fa8 "\220\340\360\330\327\177"}}, oq_abandon = {rs_msgid = 1}, oq_cancel = {rs_msgid = 1}, oq_extended = {rs_reqoid = {bv_len = 1, bv_val = 0xffffffffffffffff <Address 0xffffffffffffffff out of bounds>}, rs_flags = 0, rs_reqdata = 0x1}, oq_pwdexop = { rs_extended = {rs_reqoid = {bv_len = 1, bv_val = 0xffffffffffffffff <Address 0xffffffffffffffff out of bounds>}, rs_flags = 0, rs_reqdata = 0x1}, rs_old = { bv_len = 7728480, bv_val = 0x7fd7d8f0e410 "\246"}, rs_new = {bv_len = 27, bv_val = 0xff6fa8 "\220\340\360\330\327\177"}, 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 = 1 '\001', 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 = 0x7fd7d8f0e718, o_authz = {sai_method = 0, sai_mech = {bv_len = 0, bv_val = 0x0}, sai_dn = {bv_len = 9, bv_val = 0x8aa2e0 "cn=config"}, sai_ndn = {bv_len = 9, bv_val = 0x8a9f60 "cn=config"}, sai_ssf = 0, sai_transport_ssf = 0, sai_tls_ssf = 0, sai_sasl_ssf = 0}, o_ber = 0x0, o_res_ber = 0x0, o_callback = 0xff6fa8, o_ctrls = 0x0, o_csn = {bv_len = 40, bv_val = 0x7fd7d8f0eae0 "20120217232851.734636Z#000000#000#000000"}, o_private = 0x0, o_extra = {slh_first = 0x7fd7d8f0def0}, o_next = {stqe_next = 0x0}}, ob_hdr = { oh_opid = 0, oh_connid = 18446744073709551615, oh_conn = 0x7fd7d8f0e820, oh_msgid = 0, oh_protocol = 0, oh_tid = 140565034366720, oh_threadctx = 0x7fd7d8f0eb70, oh_tmpmemctx = 0x937190, oh_tmpmfuncs = 0x75f320, oh_counters = 0x7627a0, oh_log_prefix = "conn=-1 op=0", '\000' <repeats 243 times>}, ob_controls = {0x0 <repeats 32 times>}} op = 0x7fd7d8f0e460 rs = {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} cb = {sc_next = 0x0, sc_response = 0x7ffff09ee89e <log_old_lookup>, sc_cleanup = 0, sc_private = 0x7fd7d8f0e380} f = {f_choice = 166, f_un = {f_un_result = -655301648, f_un_desc = 0x7fd7d8f0e3f0, f_un_ava = 0x7fd7d8f0e3f0, f_un_ssa = 0x7fd7d8f0e3f0, f_un_mra = 0x7fd7d8f0e3f0, f_un_complex = 0x7fd7d8f0e3f0}, f_next = 0x0} ava = {aa_desc = 0x827c40, aa_value = {bv_len = 15, bv_val = 0x7fd7d8f0eb20 "20120218223502Z"}} pd = {slots = 200, used = 132, dn = 0x93cdd0, ndn = 0x93da60, csn = {bv_len = 40, bv_val = 0x7fd7d8f0eae0 "20120217232851.734636Z#000000#000#000000"}} timebuf = "20120218223502Z\000\300\371\360\330\327\177" csnbuf = "20120217232851.734636Z#000000#000#000000", '\000' <repeats 17 times>"\367, \360\330\327\177\000" old = 1329604502 __PRETTY_FUNCTION__ = "accesslog_purge" #12 0x00007ffff7b8cca9 in ldap_int_thread_pool_wrapper (xpool=0x7d6730) at tpool.c:688 pool = 0x7d6730 task = 0x929950 work_list = 0x7d67c8 ctx = {ltu_id = 140565034366720, ltu_key = {{ltk_key = 0x4b36e3, ltk_data = 0x937190, ltk_free = 0x4b3508 <slap_sl_mem_destroy>}, {ltk_key = 0x7fffda113010, ltk_data = 0x9371d0, ltk_free = 0x7ffff105344b <mdb_reader_free>}, {ltk_key = 0x7ffff10492ec, ltk_data = 0x7fd7d640b010, ltk_free = 0x7ffff10492c9 <search_stack_free>}, { ltk_key = 0x7ffff1046cd1, ltk_data = 0x7fd7d740c010, ltk_free = 0x7ffff1046c89 <scope_chunk_free>}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0} <repeats 25 times>, { ltk_key = 0x0, ltk_data = 0x7ffff71a0ca9, ltk_free = 0}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0}}} kctx = 0x0 i = 32 keyslot = 629 hash = 1409472117 __PRETTY_FUNCTION__ = "ldap_int_thread_pool_wrapper" #13 0x00007ffff719f9ca in start_thread () from /lib/libpthread.so.0 No symbol table info available. #14 0x00007ffff607c70d in clone () from /lib/libc.so.6 No symbol table info available. #15 0x0000000000000000 in ?? () No symbol table info available.

1 0

Re: (ITS#7157) UTF-8 support for "mail" attribute
by Kurt＠OpenLDAP.org 19 Feb '12

19 Feb '12

BTW, the IETF just published International Email stuff as Proposed. And, at brief look at it, yes, it does seem like they use UTF-8 on the wire with fallback to some ASCII address if the wire doesn't support the UTF8 extension. For White Pages applications, one could see it desirable to have a UTF-8 version of 'mail'. Fallback, if one considers it, looks to be messy. Probably would be good for some email MTA and MUA developers to sort out what want in the directory and put forth an I-D here (with the help of some directory folks). -- Kurt

1 0

Re: (ITS#6945) nssov does not build on older Linux distributions (RHEL3, RHEL4)
by h.b.furuseth＠usit.uio.no 19 Feb '12

19 Feb '12

I wrote: > If that's not it, run the gcc compile command but replace '-c (-o > foo.o)' with '-E -dD -o foo.i' Hm... or '-E -dD > foo.i' which doesn't delete foo.i on failure. -- Hallvard

1 0

Re: (ITS#6945) nssov does not build on older Linux distributions (RHEL3, RHEL4)
by h.b.furuseth＠usit.uio.no 19 Feb '12

19 Feb '12

smbk5pwd is the strangest failure, since there are no #includes preceding portable.h and slap.h to interfere. My guess is RHEL[34] need a compilation flag like -pthread to enable threading. If you can still test this, check against which options OpenLDAP uses when compiling an overlay in slapd/overlays/. If that's not it, run the gcc compile command but replace '-c (-o foo.o)' with '-E -dD -o foo.i' This puts the preprocessor output plus macro definitions in foo.i, which should ease comparing with the /usr/include/ files and see why the pthread_rwlock_t def is excluded. -- Hallvard

1 0

Re: (ITS#6883) Improved Makefiles for contrib modules
by h.b.furuseth＠usit.uio.no 18 Feb '12

18 Feb '12

On Thu, 16 Feb 2012 11:38:13 GMT, bgmilne(a)staff.telkomsa.net wrote: > Please let me know how we can get this patch merged. OpenLDAP needs more active developers... Anyway: It should remove GNU Make dependencies, not introduce them: Only use '$<' in inference rules, not explicit target rules (like ITS#7160). Drop '%.x: %.y' rules. I've scribbled a draft for that at repo <http://folk.uio.no/hbf/OpenLDAP/openldap.git>, branch its6883. (Not tested, and I need to install a non-Gnu Make to test with too.) I'll work at it later, but don't quite know when. Unless you beat me to it. Also I suppose '+=' should go away. Which I would mean move what is added to a new variable so the user can easily say things like make CPPFLAGS='-Dwhatever $(DEFS)'. Or maybe use LT_CPPFLAGS= ..whatever $(CPPFLAGS) ... like e.g. slapd/overlays/Makefile ends up doing. THat one has an awful number of Make variables and is fairly unreadable to me, probably to satisfy autoconf & co. But a few more vars seems useful. -- Hallvard

1 0

Re: (ITS#7173) Patch: Fixing prototype of function in manpage to match prototype in C header.
by hyc＠symas.com 18 Feb '12

18 Feb '12

syzdek(a)bindlebinaries.com wrote: > Full_Name: David M. Syzdek > Version: MIGRATION_CVS2GIT-630-g463c1fa > OS: OS X 10.7 > URL: http://bindlebinaries.com/patches/openldap/0001-Fixing-prototype-of-functio… > Submission from: (NULL) (209.193.42.108) > > > The prototype for ldap_modify_ext() in the C header file declares msgidp as "int > *", however the current manpage declares msgidp as "int **". This patch updates > the manpage to accurately reflect the C header. > > The attached patch file is derived from OpenLDAP Software. All of the > modifications to OpenLDAP Software represented in the following patch(es) were > developed by David M. Syzdek syzdek(a)bindlebinaries.com. I have not assigned > rights and/or interest in this work to any party. Thanks, applied to git master. > > I, David M. Syzdek, hereby place the following modifications to OpenLDAP > Software (and only these modifications) into the public domain. Hence, these > modifications may be freely used and/or redistributed for any purpose with or > without attribution and/or other notice. > > SHA1 (./0001-Fixing-prototype-of-function-in-manpage-to-match-pro.patch) = > 4d088491dd02bbc1c2884d08ae90b415d4aa5d87 > MD5 (./0001-Fixing-prototype-of-function-in-manpage-to-match-pro.patch) = > e0f1ddc73c937d15629e11183f409028 > > -- -- 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#7160) MDB-back is not buildable on HP-UX 11.31
by h.b.furuseth＠usit.uio.no 18 Feb '12

18 Feb '12

Fixed in Git master. Please test: http://www.openldap.org/devel/gitweb.cgi?p=openldap.git;h=465942e74ddbd8c5 Also fixed contrib/ldaptcl which had the same bug. POSIX 'make' does not specify '$<' for target rules (rules that name an explicit target), only for inference rules: http://pubs.opengroup.org/onlinepubs/009695399/utilities/make.html Maybe because $< would be ambiguous in target rules with several dependencies. GNU 'make' defines it as the 1st dependency. -- Hallvard

1 0

(ITS#7173) Patch: Fixing prototype of function in manpage to match prototype in C header.
by syzdek＠bindlebinaries.com 18 Feb '12

18 Feb '12

Full_Name: David M. Syzdek Version: MIGRATION_CVS2GIT-630-g463c1fa OS: OS X 10.7 URL: http://bindlebinaries.com/patches/openldap/0001-Fixing-prototype-of-functio… Submission from: (NULL) (209.193.42.108) The prototype for ldap_modify_ext() in the C header file declares msgidp as "int *", however the current manpage declares msgidp as "int **". This patch updates the manpage to accurately reflect the C header. The attached patch file is derived from OpenLDAP Software. All of the modifications to OpenLDAP Software represented in the following patch(es) were developed by David M. Syzdek syzdek(a)bindlebinaries.com. I have not assigned rights and/or interest in this work to any party. I, David M. Syzdek, hereby place the following modifications to OpenLDAP Software (and only these modifications) into the public domain. Hence, these modifications may be freely used and/or redistributed for any purpose with or without attribution and/or other notice. SHA1 (./0001-Fixing-prototype-of-function-in-manpage-to-match-pro.patch) = 4d088491dd02bbc1c2884d08ae90b415d4aa5d87 MD5 (./0001-Fixing-prototype-of-function-in-manpage-to-match-pro.patch) = e0f1ddc73c937d15629e11183f409028

1 0

Re: ITS#6598
by quanah＠zimbra.com 17 Feb '12

17 Feb '12

--On Saturday, February 18, 2012 12:41 AM +0000 quanah(a)zimbra.com wrote: > --On Saturday, February 18, 2012 1:32 AM +0100 masarati(a)aero.polimi.it > wrote: > ah, ok thanks. :) Any particularly reason why the control can't be made critical? 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

1 0

Re: ITS#6598
by quanah＠zimbra.com 17 Feb '12

17 Feb '12

--On Saturday, February 18, 2012 1:32 AM +0100 masarati(a)aero.polimi.it wrote: >> --On Thursday, September 09, 2010 6:45 PM +0000 masarati(a)aero.polimi.it >> wrote: >> >>> Committed to HEAD; please test. Thanks, p. >> >> >> Doesn't appear to work to me. >> >> This search returns 15 entries normally: >> >> ldapsearch -x -H ldapi:/// -D cn=config -w zimbra -b "" >> '(objectClass=zimbraAccount)' zimbraId >> >> # numResponses: 16 >> # numEntries: 15 >> >> >> If you choose the control you get: >> >> zimbra@zre-ldap003:~$ ldapsearch -x -H ldapi:/// -D cn=config -w zimbra >> -b "" -e '1.3.6.1.4.1.4203.666.5.18' '(objectClass=zimbraAccount)' >> zimbraId >> # extended LDIF >> # >> # LDAPv3 >> # base <> with scope subtree >> # filter: (objectClass=zimbraAccount) >> # requesting: zimbraId >> # >> >> # search result >> search: 2 >> result: 0 Success >> control: 1.3.6.1.4.1.4203.666.5.18 false MAkCAQACAQ8CAQA= > > I think it works as expected: > > $ echo -n 'MAkCAQACAQ8CAQA=' | base64 -d | od -x > 0000000 0930 0102 0200 0f01 0102 0000 > > re-ordered: > > 0x30 ber sequence > 0x09 length (9 bytes) > > 0x02 ber int > 0x01 length (1 byte) > 0x00 "0" (value of would be search result code) > > 0x02 ber int > 0x01 length (1 byte) > 0x0f "15" (number of would be returned entries) > > 0x02 ber int > 0x01 length (1 byte) > 0x00 "0" (number of would be returned search refs) ah, ok 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

1 0

Re: ITS#6598
by masarati＠aero.polimi.it 17 Feb '12

17 Feb '12

> --On Thursday, September 09, 2010 6:45 PM +0000 masarati(a)aero.polimi.it > wrote: > >> Committed to HEAD; please test. Thanks, p. > > > Doesn't appear to work to me. > > This search returns 15 entries normally: > > ldapsearch -x -H ldapi:/// -D cn=config -w zimbra -b "" > '(objectClass=zimbraAccount)' zimbraId > > # numResponses: 16 > # numEntries: 15 > > > If you choose the control you get: > > zimbra@zre-ldap003:~$ ldapsearch -x -H ldapi:/// -D cn=config -w zimbra -b > "" -e '1.3.6.1.4.1.4203.666.5.18' '(objectClass=zimbraAccount)' zimbraId > # extended LDIF > # > # LDAPv3 > # base <> with scope subtree > # filter: (objectClass=zimbraAccount) > # requesting: zimbraId > # > > # search result > search: 2 > result: 0 Success > control: 1.3.6.1.4.1.4203.666.5.18 false MAkCAQACAQ8CAQA= I think it works as expected: $ echo -n 'MAkCAQACAQ8CAQA=' | base64 -d | od -x 0000000 0930 0102 0200 0f01 0102 0000 re-ordered: 0x30 ber sequence 0x09 length (9 bytes) 0x02 ber int 0x01 length (1 byte) 0x00 "0" (value of would be search result code) 0x02 ber int 0x01 length (1 byte) 0x0f "15" (number of would be returned entries) 0x02 ber int 0x01 length (1 byte) 0x00 "0" (number of would be returned search refs) p. > > # numResponses: 1 > > MAkCAQACAQ8CAQA= decodes to a 0 followed by several spaces. If you try to > make it critical, it fails: > > zimbra@zre-ldap003:~$ ldapsearch -x -H ldapi:/// -D cn=config -w zimbra -b > "" -e '!1.3.6.1.4.1.4203.666.5.18' '(objectClass=zimbraAccount)' zimbraId > # extended LDIF > # > # LDAPv3 > # base <> with scope subtree > # filter: (objectClass=zimbraAccount) > # requesting: zimbraId > # > > # search result > search: 2 > result: 12 Critical extension is unavailable > text: critical control unavailable in context > > # numResponses: 1 > > > --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 > > > >

1 0

Re: ITS#6598
by quanah＠zimbra.com 17 Feb '12

17 Feb '12

--On Friday, February 17, 2012 11:48 PM +0000 quanah(a)zimbra.com wrote: > --On Thursday, September 09, 2010 6:45 PM +0000 masarati(a)aero.polimi.it > wrote: > >> Committed to HEAD; please test. Thanks, p. > > > Doesn't appear to work to me. > > This search returns 15 entries normally: > > ldapsearch -x -H ldapi:/// -D cn=config -w zimbra -b "" > '(objectClass=zimbraAccount)' zimbraId > ># numResponses: 16 ># numEntries: 15 > > > If you choose the control you get: > > zimbra@zre-ldap003:~$ ldapsearch -x -H ldapi:/// -D cn=config -w zimbra > -b "" -e '1.3.6.1.4.1.4203.666.5.18' '(objectClass=zimbraAccount)' Also, just to show it is definitely loaded: ldapsearch -x -H ldap://zre-ldap003.eng.vmware.com -s base -b "" + dn: structuralObjectClass: OpenLDAProotDSE configContext: cn=config monitorContext: cn=Monitor namingContexts: supportedControl: 1.3.6.1.4.1.4203.666.5.18 --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

1 0

Re: ITS#6598
by quanah＠zimbra.com 17 Feb '12

17 Feb '12

--On Thursday, September 09, 2010 6:45 PM +0000 masarati(a)aero.polimi.it wrote: > Committed to HEAD; please test. Thanks, p. Doesn't appear to work to me. This search returns 15 entries normally: ldapsearch -x -H ldapi:/// -D cn=config -w zimbra -b "" '(objectClass=zimbraAccount)' zimbraId # numResponses: 16 # numEntries: 15 If you choose the control you get: zimbra@zre-ldap003:~$ ldapsearch -x -H ldapi:/// -D cn=config -w zimbra -b "" -e '1.3.6.1.4.1.4203.666.5.18' '(objectClass=zimbraAccount)' zimbraId # extended LDIF # # LDAPv3 # base <> with scope subtree # filter: (objectClass=zimbraAccount) # requesting: zimbraId # # search result search: 2 result: 0 Success control: 1.3.6.1.4.1.4203.666.5.18 false MAkCAQACAQ8CAQA= # numResponses: 1 MAkCAQACAQ8CAQA= decodes to a 0 followed by several spaces. If you try to make it critical, it fails: zimbra@zre-ldap003:~$ ldapsearch -x -H ldapi:/// -D cn=config -w zimbra -b "" -e '!1.3.6.1.4.1.4203.666.5.18' '(objectClass=zimbraAccount)' zimbraId # extended LDIF # # LDAPv3 # base <> with scope subtree # filter: (objectClass=zimbraAccount) # requesting: zimbraId # # search result search: 2 result: 12 Critical extension is unavailable text: critical control unavailable in context # numResponses: 1 --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

1 0

Re: (ITS#7170) back-mdb indexing generation failure
by quanah＠zimbra.com 17 Feb '12

17 Feb '12

--On Friday, February 17, 2012 4:03 AM +0000 quanah(a)zimbra.com wrote: > > Further update -- If I reload the database with just "slapadd", searches > work. If I use quickmode "slapadd -q", the searches fail. So there is a > bug in index generation with quick mode slapadd. Oddly enough, it only occurs on a system that has two databases configured -- An accesslog DB for delta-syncrepl, and a DB for the primary data. --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

1 0

Re: (ITS#7172) SEGFAULT in openldap-2.4.28 & 2.4.29
by hyc＠symas.com 17 Feb '12

17 Feb '12

dcoutadeur(a)linagora.com wrote: > Full_Name: dcoutadeur > Version: 2.4.28 > OS: Red Hat Enterprise Linux Server release 5.7 (Tikanga) > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (109.197.176.10) > > > > Hello, > > > I had a segfault in the last git version of OpenLDAP, after 10 to 15 tests, each > interrupted by Ctrl+C. (see what's a test below) > The segfault is also reproduced in version 2.4.28. > > I think I won't be able to reproduce the bug with Valgrind. If you expect us to try to reproduce the bug, you'll have to provide more information. Since this crash is in syncprov there's obviously at least two servers involved; what are their configurations? What hardware are they running on (in particular, how many CPU cores per server)? Since you're using a custom client, can you provide the client source code? > > Thank you in advance for any help. > > D. > > > Note : A test is 100 times 100 threads, each doing a bind, an add, a modify, a > delete, and a logout. > > > > > > (gdb) bt full > #0 sp_avl_cmp (c1=0x8b4004c8, c2=0xa37cf28) at syncprov.c:366 > rc =<value optimized out> > #1 0x081afe3e in avl_delete (root=0xa255648, data=0x8b4004c8, > fcmp=0x81948a0<sp_avl_cmp>) at avl.c:197 > p =<value optimized out> > q =<value optimized out> > r =<value optimized out> > top =<value optimized out> > side =<value optimized out> > side_bf =<value optimized out> > shorter =<value optimized out> > nside =<value optimized out> > pptr = {0x89908, 0x0, 0x0, 0x0, 0xe8043c, 0x0, 0xfdc, > 0x8d994858, 0xe7b95c, 0xfdc, 0xa372570, 0x0, 0xa288350, > 0xe8043c, 0xa372570, 0x8d994878, 0xe7c324, 0xfdc, 0xa372570, > 0x0, 0xe7af2c, 0x8cb9136e, 0x81b3634, 0x0, 0xe8043c, > 0xe, 0xa3d3a40, 0x8d9948b8, 0xe7d081, 0xa3e3618, 0x8cb91358, > 0x823c27} > pdir = > "\000\000\000\000lI\231\215\064\066\033\bn>\000\000\244\345t\000\310\004@\213\b\346\067\n\310H\231\215" > depth = 0 > #2 0x08199f7f in syncprov_op_cleanup (op=0xa37e608, rs=0x8d995108) at > syncprov.c:1401 > cb = 0x8cb91258 > opc = 0x8cb91268 > si = 0xa255610 > sm = 0xa255688 > snext =<value optimized out> > mt = 0x8b4004c8 > #3 0x08089654 in slap_cleanup_play (op=0xa37e608, rs=0x8d995108) at > result.c:541 > sc_next = 0x8d994dec > sc = 0x8cb91258 > scp = 0x8d994928 > #4 0x0808a150 in send_ldap_response (op=0xa37e608, rs=0x8d995108) at > result.c:733 > berbuf = { > buffer = "\000\000\001\000\000\001\000\000\377\377\377\377", > '\000'<repeats 12 times>, > "f\023\271\214\064#\271\214\000\000\000\000f\023\271\214p%7\n\000\000\000\000\314I\231\215\001\000\000\000\000\000\000\000\314mK\236x\271\347\000\001\000\000\000`+@\213D`K\236\230\063\066\n\250<6\n\000\000\000\000\000\000\000\000\005\000\000\000P7@\213`\343\070\n\000\000\000\000\n\000\000\000(\234\200\330\000\000\000\000\000\000\000\000@4\"\000\000\000\000\000(\234\200\330\210J\231\215\270\214 > \000\230\063\066\n`+@\213\314mK\236\r\000\000\000\001\000\000\000\021\217;O(\234\200\330\000\000\000\000`&%\n`&%\n8J\231\215b\f\"\000\224mK\236\230\063\066\n(\234\200أ\347\022\b\a", > '\000'<repeats 31 times>, "D'%\n\224mK\236\000\000\000", > ialign = 65536, lalign = 65536, falign = 9.18354962e-41, > dalign = 5.4323095486619588e-312, > palign = 0x10000<Address 0x10000 out of bounds>} > ber =<value optimized out> > rc = 32768 > bytes = 14 > __PRETTY_FUNCTION__ = "send_ldap_response" > #5 0x0808af1f in slap_send_ldap_result (op=0xa37e608, rs=0x8d995108) at > result.c:860 > tmp = 0x0 > otext = 0x0 > oref = 0x0 > __PRETTY_FUNCTION__ = "slap_send_ldap_result" > #6 0x0812bde5 in bdb_add (op=0xa37e608, rs=0x8d995108) at add.c:511 > pdn = {bv_len = 23, bv_val = 0x8b40372f "ou=people,dc=afp,dc=com"} > p = 0x8fc4c0fc > oe = 0x8fc4c804 > ei = 0xa37d1c8 > textbuf = "\000\000\000\000\320O\"\n", '\000'<repeats 48 > times>, "\001", '\000'<repeats 198 times> > children = 0xa223b20 > entry = 0xa223980 > ltid = 0x0 > lt2 = 0x8b402bf0 > eid = 57976 > opinfo = {boi_oe = {oe_next = {sle_next = 0x8d99509c}, oe_key = > 0x0}, boi_txn = 0x8b402b60, boi_locks = 0x0, > boi_err = 0, boi_acl_cache = 0 '\000', boi_flag = 0 '\000'} > lock = {off = 133260, ndx = 772, gen = 2004, mode = DB_LOCK_READ} > num_retries = 0 > success = 0 > postread_ctrl = 0x0 > ctrls = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0} > num_ctrls = 0 > #7 0x080e33a1 in overlay_op_walk (op=0xa37e608, rs=0x8d995108, > which=op_add, oi=0xa254ff0, on=0xa255508) at backover.c:671 > rc = 32768 > #8 0x080e3a0a in over_op_func (op=0xa37e608, rs=0x8d995108, > which=op_add) at backover.c:723 > oi = 0xa254ff0 > on = 0xa255508 > be = 0xa252560 > db = {bd_info = 0x821d41c, bd_self = 0xa252560, > be_ctrls = > "\000\001\001\001\000\001\000\000\001\000\000\001\001\000\001\001\000\000\000\000\001\000\001\000\000\000\000\000\000\000\000\000\001", > be_flags = 563464, 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 = > 0xa288350, be_nsuffix = 0xa288368, be_schemadn = { > bv_len = 0, bv_val = 0x0}, be_schemandn = {bv_len = 0, > bv_val = 0x0}, be_rootdn = {bv_len = 24, > bv_val = 0xa287648 "cn=Manager,dc=afp,dc=com"}, be_rootndn = > {bv_len = 24, > bv_val = 0xa2876d0 "cn=manager,dc=afp,dc=com"}, be_rootpw = > {bv_len = 38, > bv_val = 0xa2876f0 > "{SSHA}rEmMhg3MU5xkQX5Ng92tH4WzGMlA+nGU"}, be_max_deref_depth = 15, > be_def_limit = { > lms_t_soft = 3600, lms_t_hard = 0, lms_s_soft = 15000, > lms_s_hard = 0, lms_s_unchecked = -1, lms_s_pr = 0, > lms_s_pr_hide = 0, lms_s_pr_total = 0}, be_limits = > 0xa255748, be_acl = 0x0, 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 = 0xa363388, be_pcl_mutex = {__data = > {__lock = 0, __count = 0, __owner = 0, __kind = 0, > __nusers = 0, {__spins = 0, __list = {__next = 0x0}}}, > __size = '\000'<repeats 23 times>, __align = 0}, > be_syncinfo = 0xa28aec8, be_pb = 0x0, be_cf_ocs = 0x821f840, > be_private = 0xa252660, be_next = { > stqe_next = 0xa288538}} > cb = {sc_next = 0x0, sc_response = 0x80e30e0 > <over_back_response>, sc_cleanup = 0, sc_private = 0xa254ff0} > sc =<value optimized out> > rc =<value optimized out> > __PRETTY_FUNCTION__ = "over_op_func" > #9 0x08081129 in fe_op_add (op=0xa37e608, rs=0x8d995108) at add.c:334 > repl_user = 0 > rc =<value optimized out> > bd = 0x82234c0 > textbuf = > "\000\000\000\000\000\000\000\000\060[\231\215\000\000\000\000\035\000\000\000\020\070@\213\001\000\000\000xN\231\215\270\026@\213(I\"\n\002\000\000\000\250N\231\215\255\214\v\b\270\026@\213\224N\231\215\001\000\000\000\000\000\000\000x9@\213\000\000\000\000\n\000\000\000\001\000\000\000\340\067@\213\n\000\000\000\060\070@\213\320\026@\213(I\"\n\270\026@\213\370N\231\215oc\t\b\002\000\000\000X( > \n\370N\231\215\321_\t\bh\234!\n\240\066@\213'<\202\000\000\000\000\000\f\000\000\000W.@\213n>\000\000\244\345t\000\320O\"\n\320O\"\n\370N\231\215\035\205q\000 > .\"\b\314h\032\216\030O\231\215\245\063\b\b > .\"\b\240\066@\213\000\000\000\000\270\026@\213\244i\032\216\000\000\000\000HO\231\215\267\r\b\b\320O\"\n\320O\"\n\001\000\000\000HO\231\215\020\000\000\000\340h\032\216\377\377\377\377" > __PRETTY_FUNCTION__ = "fe_op_add" > #10 0x08081a13 in do_add (op=0xa37e608, rs=0x8d995108) at add.c:194 > ber =<value optimized out> > last = 0x8b402e71 "" > dn = {bv_len = 38, bv_val = 0x8b402d98 > "uid=dcoutadeur,ou=People,dc=afp,dc=com"} > len = 28 > tag =<value optimized out> > modlist = 0x8b4015f0 > modtail = 0x8b403694 > tmp = {sml_mod = {sm_desc = 0x80ce5ca, sm_values = 0x8b4036a0, > sm_nvalues = 0x0, sm_numvals = 2375635128, > sm_op = 0, sm_flags = 0, sm_type = {bv_len = 12, bv_val = > 0x8b402e57 "userPassword"}}, sml_next = 0x823c27} > textbuf = > "\025\000\000\000\310\031@\213\b\026@\213\006\340(\000\220[\231\215\000\000\000\000\000\000\000\000\020\000@\213\025\000\000\000\310\031@\213\310+@\213\005\070/\000\200O@\213T\245(\000\000\000\000\000\020\000@\213\364\237\067\000\220[\231\215\000\000\000\000\233\071@\213@:=\n\370O\231\215T\213\202\000b\213\202\000;\334\347\000\"\000\000\000\233\071@\213\b\000\000\000\201\354(\000\fP\231\215<\004\350\000\270P\231\215\312\315\347\000\370\326\070\n\233\071@\213\b\000\000\000\001\200\255\373\b\347\067\n@\000\000\000\243P\231\215@\000@\213\026\347\067\n@\000@\213\b\347\067\n@\261\067\000,\000\000\000\020\000@\213", > '\000'<repeats 20 times>, > "5\000\000\000@\000@\213\000\000\000\000\340\021@\213\000\000\000\000\000\000\000\000\260+@\213\000\000\000\000\001\000\000\000\004\000\020\000\350Q\231\215\310P\231\215" > rc =<value optimized out> > freevals =<value optimized out> > oex = {oe = {oe_next = {sle_next = 0x0}, oe_key = 0x8081330}, > oe_db = 0x0} > #11 0x0807988c in connection_operation (ctx=0x8d9951e8, arg_v=0xa37e608) > at connection.c:1150 > rc =<value optimized out> > cancel =<value optimized out> > rs = {sr_type = REP_RESULT, sr_tag = 105, 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} > tag = 104 > opidx = SLAP_OP_ADD > conn = 0xb7f3bc10 > memctx = 0xa372570 > memctx_null = 0x0 > __PRETTY_FUNCTION__ = "connection_operation" > #12 0x0807a0fd in connection_read_thread (ctx=0x8d9951e8, argv=0x22) at > connection.c:1286 > s =<value optimized out> > #13 0x00717a24 in ldap_int_thread_pool_wrapper (xpool=0xa2265c8) at > tpool.c:688 > task = 0xa382e10 > work_list =<value optimized out> > ctx = {ltu_id = 2375637904, ltu_key = {{ltk_key = 0x80ce400, > ltk_data = 0xa372570, > ltk_free = 0x80ce430<slap_sl_mem_destroy>}, {ltk_key = > 0xa363398, ltk_data = 0xa371a88, > ltk_free = 0x812e4c0<bdb_reader_free>}, {ltk_key = > 0x8078320, ltk_data = 0xa37de68, > ltk_free = 0x80783f0<conn_counter_destroy>}, {ltk_key = > 0x808dde0, ltk_data = 0x0, > ltk_free = 0x808dbf0<slap_op_q_destroy>}, {ltk_key = 0x0, > ltk_data = 0x0, ltk_free = 0}<repeats 28 times>}} > kctx =<value optimized out> > keyslot = 241 > hash = 5278961 > __PRETTY_FUNCTION__ = "ldap_int_thread_pool_wrapper" > #14 0x00821832 in start_thread () from /lib/libpthread.so.0 > No symbol table info available. > #15 0x002f746e in clone () from /lib/libc.so.6 > No symbol table info available. > > > > > -- -- 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

(ITS#7172) SEGFAULT in openldap-2.4.28 & 2.4.29
by dcoutadeur＠linagora.com 17 Feb '12

17 Feb '12

Full_Name: dcoutadeur Version: 2.4.28 OS: Red Hat Enterprise Linux Server release 5.7 (Tikanga) URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (109.197.176.10) Hello, I had a segfault in the last git version of OpenLDAP, after 10 to 15 tests, each interrupted by Ctrl+C. (see what's a test below) The segfault is also reproduced in version 2.4.28. I think I won't be able to reproduce the bug with Valgrind. Thank you in advance for any help. D. Note : A test is 100 times 100 threads, each doing a bind, an add, a modify, a delete, and a logout. (gdb) bt full #0 sp_avl_cmp (c1=0x8b4004c8, c2=0xa37cf28) at syncprov.c:366 rc = <value optimized out> #1 0x081afe3e in avl_delete (root=0xa255648, data=0x8b4004c8, fcmp=0x81948a0 <sp_avl_cmp>) at avl.c:197 p = <value optimized out> q = <value optimized out> r = <value optimized out> top = <value optimized out> side = <value optimized out> side_bf = <value optimized out> shorter = <value optimized out> nside = <value optimized out> pptr = {0x89908, 0x0, 0x0, 0x0, 0xe8043c, 0x0, 0xfdc, 0x8d994858, 0xe7b95c, 0xfdc, 0xa372570, 0x0, 0xa288350, 0xe8043c, 0xa372570, 0x8d994878, 0xe7c324, 0xfdc, 0xa372570, 0x0, 0xe7af2c, 0x8cb9136e, 0x81b3634, 0x0, 0xe8043c, 0xe, 0xa3d3a40, 0x8d9948b8, 0xe7d081, 0xa3e3618, 0x8cb91358, 0x823c27} pdir = "\000\000\000\000lI\231\215\064\066\033\bn>\000\000\244\345t\000\310\004@\213\b\346\067\n\310H\231\215" depth = 0 #2 0x08199f7f in syncprov_op_cleanup (op=0xa37e608, rs=0x8d995108) at syncprov.c:1401 cb = 0x8cb91258 opc = 0x8cb91268 si = 0xa255610 sm = 0xa255688 snext = <value optimized out> mt = 0x8b4004c8 #3 0x08089654 in slap_cleanup_play (op=0xa37e608, rs=0x8d995108) at result.c:541 sc_next = 0x8d994dec sc = 0x8cb91258 scp = 0x8d994928 #4 0x0808a150 in send_ldap_response (op=0xa37e608, rs=0x8d995108) at result.c:733 berbuf = { buffer = "\000\000\001\000\000\001\000\000\377\377\377\377", '\000' <repeats 12 times>, "f\023\271\214\064#\271\214\000\000\000\000f\023\271\214p%7\n\000\000\000\000\314I\231\215\001\000\000\000\000\000\000\000\314mK\236x\271\347\000\001\000\000\000`+@\213D`K\236\230\063\066\n\250<6\n\000\000\000\000\000\000\000\000\005\000\000\000P7@\213`\343\070\n\000\000\000\000\n\000\000\000(\234\200\330\000\000\000\000\000\000\000\000@4\"\000\000\000\000\000(\234\200\330\210J\231\215\270\214 \000\230\063\066\n`+@\213\314mK\236\r\000\000\000\001\000\000\000\021\217;O(\234\200\330\000\000\000\000`&%\n`&%\n8J\231\215b\f\"\000\224mK\236\230\063\066\n(\234\200أ\347\022\b\a", '\000' <repeats 31 times>, "D'%\n\224mK\236\000\000\000", ialign = 65536, lalign = 65536, falign = 9.18354962e-41, dalign = 5.4323095486619588e-312, palign = 0x10000 <Address 0x10000 out of bounds>} ber = <value optimized out> rc = 32768 bytes = 14 __PRETTY_FUNCTION__ = "send_ldap_response" #5 0x0808af1f in slap_send_ldap_result (op=0xa37e608, rs=0x8d995108) at result.c:860 tmp = 0x0 otext = 0x0 oref = 0x0 __PRETTY_FUNCTION__ = "slap_send_ldap_result" #6 0x0812bde5 in bdb_add (op=0xa37e608, rs=0x8d995108) at add.c:511 pdn = {bv_len = 23, bv_val = 0x8b40372f "ou=people,dc=afp,dc=com"} p = 0x8fc4c0fc oe = 0x8fc4c804 ei = 0xa37d1c8 textbuf = "\000\000\000\000\320O\"\n", '\000' <repeats 48 times>, "\001", '\000' <repeats 198 times> children = 0xa223b20 entry = 0xa223980 ltid = 0x0 lt2 = 0x8b402bf0 eid = 57976 opinfo = {boi_oe = {oe_next = {sle_next = 0x8d99509c}, oe_key = 0x0}, boi_txn = 0x8b402b60, boi_locks = 0x0, boi_err = 0, boi_acl_cache = 0 '\000', boi_flag = 0 '\000'} lock = {off = 133260, ndx = 772, gen = 2004, mode = DB_LOCK_READ} num_retries = 0 success = 0 postread_ctrl = 0x0 ctrls = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0} num_ctrls = 0 #7 0x080e33a1 in overlay_op_walk (op=0xa37e608, rs=0x8d995108, which=op_add, oi=0xa254ff0, on=0xa255508) at backover.c:671 rc = 32768 #8 0x080e3a0a in over_op_func (op=0xa37e608, rs=0x8d995108, which=op_add) at backover.c:723 oi = 0xa254ff0 on = 0xa255508 be = 0xa252560 db = {bd_info = 0x821d41c, bd_self = 0xa252560, be_ctrls = "\000\001\001\001\000\001\000\000\001\000\000\001\001\000\001\001\000\000\000\000\001\000\001\000\000\000\000\000\000\000\000\000\001", be_flags = 563464, 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 = 0xa288350, be_nsuffix = 0xa288368, be_schemadn = { bv_len = 0, bv_val = 0x0}, be_schemandn = {bv_len = 0, bv_val = 0x0}, be_rootdn = {bv_len = 24, bv_val = 0xa287648 "cn=Manager,dc=afp,dc=com"}, be_rootndn = {bv_len = 24, bv_val = 0xa2876d0 "cn=manager,dc=afp,dc=com"}, be_rootpw = {bv_len = 38, bv_val = 0xa2876f0 "{SSHA}rEmMhg3MU5xkQX5Ng92tH4WzGMlA+nGU"}, be_max_deref_depth = 15, be_def_limit = { lms_t_soft = 3600, lms_t_hard = 0, lms_s_soft = 15000, lms_s_hard = 0, lms_s_unchecked = -1, lms_s_pr = 0, lms_s_pr_hide = 0, lms_s_pr_total = 0}, be_limits = 0xa255748, be_acl = 0x0, 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 = 0xa363388, be_pcl_mutex = {__data = {__lock = 0, __count = 0, __owner = 0, __kind = 0, __nusers = 0, {__spins = 0, __list = {__next = 0x0}}}, __size = '\000' <repeats 23 times>, __align = 0}, be_syncinfo = 0xa28aec8, be_pb = 0x0, be_cf_ocs = 0x821f840, be_private = 0xa252660, be_next = { stqe_next = 0xa288538}} cb = {sc_next = 0x0, sc_response = 0x80e30e0 <over_back_response>, sc_cleanup = 0, sc_private = 0xa254ff0} sc = <value optimized out> rc = <value optimized out> __PRETTY_FUNCTION__ = "over_op_func" #9 0x08081129 in fe_op_add (op=0xa37e608, rs=0x8d995108) at add.c:334 repl_user = 0 rc = <value optimized out> bd = 0x82234c0 textbuf = "\000\000\000\000\000\000\000\000\060[\231\215\000\000\000\000\035\000\000\000\020\070@\213\001\000\000\000xN\231\215\270\026@\213(I\"\n\002\000\000\000\250N\231\215\255\214\v\b\270\026@\213\224N\231\215\001\000\000\000\000\000\000\000x9@\213\000\000\000\000\n\000\000\000\001\000\000\000\340\067@\213\n\000\000\000\060\070@\213\320\026@\213(I\"\n\270\026@\213\370N\231\215oc\t\b\002\000\000\000X( \n\370N\231\215\321_\t\bh\234!\n\240\066@\213'<\202\000\000\000\000\000\f\000\000\000W.@\213n>\000\000\244\345t\000\320O\"\n\320O\"\n\370N\231\215\035\205q\000 .\"\b\314h\032\216\030O\231\215\245\063\b\b .\"\b\240\066@\213\000\000\000\000\270\026@\213\244i\032\216\000\000\000\000HO\231\215\267\r\b\b\320O\"\n\320O\"\n\001\000\000\000HO\231\215\020\000\000\000\340h\032\216\377\377\377\377" __PRETTY_FUNCTION__ = "fe_op_add" #10 0x08081a13 in do_add (op=0xa37e608, rs=0x8d995108) at add.c:194 ber = <value optimized out> last = 0x8b402e71 "" dn = {bv_len = 38, bv_val = 0x8b402d98 "uid=dcoutadeur,ou=People,dc=afp,dc=com"} len = 28 tag = <value optimized out> modlist = 0x8b4015f0 modtail = 0x8b403694 tmp = {sml_mod = {sm_desc = 0x80ce5ca, sm_values = 0x8b4036a0, sm_nvalues = 0x0, sm_numvals = 2375635128, sm_op = 0, sm_flags = 0, sm_type = {bv_len = 12, bv_val = 0x8b402e57 "userPassword"}}, sml_next = 0x823c27} textbuf = "\025\000\000\000\310\031@\213\b\026@\213\006\340(\000\220[\231\215\000\000\000\000\000\000\000\000\020\000@\213\025\000\000\000\310\031@\213\310+@\213\005\070/\000\200O@\213T\245(\000\000\000\000\000\020\000@\213\364\237\067\000\220[\231\215\000\000\000\000\233\071@\213@:=\n\370O\231\215T\213\202\000b\213\202\000;\334\347\000\"\000\000\000\233\071@\213\b\000\000\000\201\354(\000\fP\231\215<\004\350\000\270P\231\215\312\315\347\000\370\326\070\n\233\071@\213\b\000\000\000\001\200\255\373\b\347\067\n@\000\000\000\243P\231\215@\000@\213\026\347\067\n@\000@\213\b\347\067\n@\261\067\000,\000\000\000\020\000@\213", '\000' <repeats 20 times>, "5\000\000\000@\000@\213\000\000\000\000\340\021@\213\000\000\000\000\000\000\000\000\260+@\213\000\000\000\000\001\000\000\000\004\000\020\000\350Q\231\215\310P\231\215" rc = <value optimized out> freevals = <value optimized out> oex = {oe = {oe_next = {sle_next = 0x0}, oe_key = 0x8081330}, oe_db = 0x0} #11 0x0807988c in connection_operation (ctx=0x8d9951e8, arg_v=0xa37e608) at connection.c:1150 rc = <value optimized out> cancel = <value optimized out> rs = {sr_type = REP_RESULT, sr_tag = 105, 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} tag = 104 opidx = SLAP_OP_ADD conn = 0xb7f3bc10 memctx = 0xa372570 memctx_null = 0x0 __PRETTY_FUNCTION__ = "connection_operation" #12 0x0807a0fd in connection_read_thread (ctx=0x8d9951e8, argv=0x22) at connection.c:1286 s = <value optimized out> #13 0x00717a24 in ldap_int_thread_pool_wrapper (xpool=0xa2265c8) at tpool.c:688 task = 0xa382e10 work_list = <value optimized out> ctx = {ltu_id = 2375637904, ltu_key = {{ltk_key = 0x80ce400, ltk_data = 0xa372570, ltk_free = 0x80ce430 <slap_sl_mem_destroy>}, {ltk_key = 0xa363398, ltk_data = 0xa371a88, ltk_free = 0x812e4c0 <bdb_reader_free>}, {ltk_key = 0x8078320, ltk_data = 0xa37de68, ltk_free = 0x80783f0 <conn_counter_destroy>}, {ltk_key = 0x808dde0, ltk_data = 0x0, ltk_free = 0x808dbf0 <slap_op_q_destroy>}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0} <repeats 28 times>}} kctx = <value optimized out> keyslot = 241 hash = 5278961 __PRETTY_FUNCTION__ = "ldap_int_thread_pool_wrapper" #14 0x00821832 in start_thread () from /lib/libpthread.so.0 No symbol table info available. #15 0x002f746e in clone () from /lib/libc.so.6 No symbol table info available.

1 0

Re: (ITS#7171) RefInt overlay: olcRefIntNothing doesn't kick in when deleting last member from group
by h.b.furuseth＠usit.uio.no 17 Feb '12

17 Feb '12

Looks like a duplicate of ITS#6663, which was fixed in OpenLDAP 2.4.24.

1 0

(ITS#7171) RefInt overlay: olcRefIntNothing doesn't kick in when deleting last member from group
by p.nijs＠xs4all.nl 17 Feb '12

17 Feb '12

Full_Name: Patrick Nijs Version: 2.4.23 OS: Debian Squeeze x86 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (2001:980:74b5:1:bcd8:7053:70b4:377d) I have a clean install of Debian Squeeze, and a clean install of OpenLDAP. Now I have enabled the REFINT overlay (it's the only overlay I am using): To enable it, I executed the following commands as root: echo " dn: cn=module{0},cn=config add: olcModuleLoad olcModuleLoad: refint " | ldapmodify -Y EXTERNAL -H ldapi:/// and: echo " dn: olcOverlay=refint,olcDatabase={1}hdb,cn=config changetype: add objectClass: olcRefintConfig objectClass: olcOverlayConfig objectClass: olcConfig objectClass: top olcOverlay: refint olcRefintAttribute: member olcRefintNothing: cn=admin,dc=domain,dc=local " | ldapmodify -Y EXTERNAL -H ldapi:/// The good thing is that if I rename the DN of a group member, all goes well. The only BAD thing is, that when I delete a user which is the ONLY MEMBER OF A GROUP, then the olcRefintNothing does NOT KICK IN. I expect that that when the last member of a group is deleted, then the member attribute of that group is replaced with the DN as specified in olcRefintNothing. This doesn't happen. Here is a snippet from my syslog (loglevel -1), where cn=test,dc=domein,dc=local is the GROUP (groupOfNames) with the member ATTRIBUTE. uid=peter1,dc=domein,dc=local is a User (account) and the only member left in the aforementioned group. When I delete this user this shows up in the log: Feb 17 13:27:27 vm03 slapd[25075]: refint_search_cb <cn=test,dc=domein,dc=local> Feb 17 13:27:27 vm03 slapd[25075]: refint_search_cb: member: uid=peter1,dc=domein,dc=local (#1) Feb 17 13:27:27 vm03 slapd[25075]: send_ldap_result: conn=-1 op=0 p=0 Feb 17 13:27:27 vm03 slapd[25075]: send_ldap_result: err=0 matched="" text="" Feb 17 13:27:27 vm03 slapd[25075]: refint_search_cb <NOTHING> Feb 17 13:27:27 vm03 slapd[25075]: hdb_modify: cn=test,dc=domein,dc=local Feb 17 13:27:27 vm03 slapd[25075]: slap_queue_csn: queing 0xb59c06b6 20120217122727.743313Z#000000#000#000000 Feb 17 13:27:27 vm03 slapd[25075]: bdb_dn2entry("cn=test,dc=domein,dc=local") Feb 17 13:27:27 vm03 slapd[25075]: bdb_modify_internal: 0x00000006: cn=test,dc=domein,dc=local Feb 17 13:27:27 vm03 slapd[25075]: <= acl_access_allowed: granted to database root Feb 17 13:27:27 vm03 slapd[25075]: bdb_modify_internal: delete member Feb 17 13:27:27 vm03 slapd[25075]: dnMatch 0#012#011"uid=peter1,dc=domein,dc=local"#012#011"uid=peter1,dc=domein,dc=local" Feb 17 13:27:27 vm03 slapd[25075]: bdb_modify_internal: replace modifiersName Feb 17 13:27:27 vm03 slapd[25075]: bdb_modify_internal: delete member Feb 17 13:27:27 vm03 slapd[25075]: bdb_modify_internal: 16 modify/delete: member: no such attribute Feb 17 13:27:27 vm03 slapd[25075]: hdb_modify: modify failed (16) Feb 17 13:27:27 vm03 slapd[25075]: send_ldap_result: conn=-1 op=0 p=0 Feb 17 13:27:27 vm03 slapd[25075]: send_ldap_result: err=16 matched="" text="modify/delete: member: no such attribute" Feb 17 13:27:27 vm03 slapd[25075]: slap_graduate_commit_csn: removing 0x938a7d0 20120217122727.743313Z#000000#000#000000 Feb 17 13:27:27 vm03 slapd[25075]: refint_repair: dependent modify failed: 16 Feb 17 13:27:27 vm03 slapd[25075]: daemon: activity on 1 descriptor I see that the REFINT overlay is kicking in, but it comes with the following error: bdb_modify_internal: 16 modify/delete: member: no such attribute That is strange, because this groupOfNames certainly has a member attribute. Is this a bug? Thanks in advance, Patrick

1 0

Re: (ITS#7170) back-mdb indexing generation failure
by quanah＠zimbra.com 16 Feb '12

16 Feb '12

--On February 17, 2012 3:22:47 AM +0000 quanah(a)zimbra.com wrote: > --On Friday, February 17, 2012 3:14 AM +0000 quanah(a)OpenLDAP.org wrote: > >> Full_Name: Quanah Gibson-Mount >> Version: 2.4.29 >> OS: Linux 2.6 >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (75.108.184.39) >> >> >> If one has a back-mdb database, some searches on the indexed attr of "cn" >> fail. I do not see this issue with an identically configured back-hdb >> install. > > In checking some other entries, it only appears to occur with the filters: > > "(cn=zimbra)" > > and > > "(cn=config)" > > All other cn=xxxx values I tested work correctly. Further update -- If I reload the database with just "slapadd", searches work. If I use quickmode "slapadd -q", the searches fail. So there is a bug in index generation with quick mode slapadd. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs