openldap-bugs

openldap-bugs@openldap.org

1 participants
20960 discussions

Re: (ITS#6022) What is idlcachesize?
by quanah＠zimbra.com 13 Mar '09

13 Mar '09

--On Friday, March 13, 2009 6:47 PM +0000 arun_patel(a)yahoo.com wrote: > Full_Name: Arun Patel > Version: 2.2.13 > OS: linux > URL: > Submission from: (NULL) (135.207.175.192) See the admin guide. Note that question should be sent to an appropriate list. The ITS system is for bug reports. I'd also note that the OpenLDAP 2.2 release is historical. OpenLDAP 2.4 is the current supported release tree. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#6022) What is idlcachesize?
by arun_patel＠yahoo.com 13 Mar '09

13 Mar '09

Full_Name: Arun Patel Version: 2.2.13 OS: linux URL: Submission from: (NULL) (135.207.175.192) Can someone explain to me idlcachesize entry in slapd.conf? What is it used for? Does it optimize? Any and all informatin will be helpful Thanks Arun

1 0

Re: (ITS#5973) Syncrepl can update more than one csn value
by rein＠OpenLDAP.org 13 Mar '09

13 Mar '09

hyc(a)symas.com wrote: > rein(a)OpenLDAP.org wrote: >> Syncrepl can update more than one csn value in one operation, but only one can >> be passed to syncprov in the csn queue. Syncprov should instead pick the >> updated values from the modify operation. > The syncrepl patch broke the CSN queue, which has caused out-of-order updates > in test050. I have reverted it. Every write operation begins with a queued CSN > and ends by graduating a CSN. You removed the enqueueing step, and so the > queue contents were invalid. I removed the queuing and graduating of the CSN syncrepl_updateCookie() would update, as that only sent one of the (possibly) many values that could be updated by that operation. With the syncprov half of the patch the queued patch should never be looked at, meaning that this queuing should be unnecessary here. The ordinary queue/graduation of the CSN received with an updated entry is still in place, and should continue to be so. >> A patch that fixes this is coming. This patch depends on the ITS#5972 patch, >> and is required for the new test058 to succeed. > > test058 has the same number of errors with or without the syncrepl patch, so I > don't think it was relevant to the issues you were addressing. It was only the syncprov half of ITS#5793 patch that was relevant for test058. The syncrepl half of the patch only removes code that should be unnecessary.. > I'm still skeptical about the syncprov half of the patch. The two patches were > actually unrelated, the syncprov patch takes effect regardless of the syncrepl > patch. Yes, the syncprov part of the patch doesn't need the syncrepl half, but I found it correct to clean up code that should be made unnecessary by that patch. All updates received during the persistent phase should include an updated CSN value, and should already have been transmitted to syncprov by the commit/graduate queue and have caused it to update its own csn set. I.e, the syncrepl_updateCookie() replace operation should only have caused syncprov to updated its cookie and thereby send NEW_COOKIE messages when syncrepl updated the CSN set at the end of the refresh phase. Apparently, there is something that causes this to break. More on that in another message on -devel. Rein

1 0

(ITS#6021) slapo-pcache/back-ldap slapd crashes
by toby＠inf.ed.ac.uk 13 Mar '09

13 Mar '09

Full_Name: Toby Blake Version: 2.4.15 OS: Scientific Linux 5.2 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (129.215.197.95) Hi there, I have been testing slapo-pcache/back-ldap for some time now, typically in student lab situations (to provide a localhost proxycaching slapd with back-ldap connecting (via gssapi) to several remote servers), initially using 2.3.x but I have recently moved to using the latest 2.4.x versions, as it's clear that's where the development effort is going. I'm seeing quite a lot of crashes during my testing, with a few different backtraces. I don't know whether you would prefer I submitted these separately for different backtraces, so I'm opening this ITS to get the process started... I have seen no way of reproducing these crashes. I'm currently using: - openldap-2.4.15 on scientific linux 5.2 - bdb 4.7.25 with 3 patches - We build our own RPMs. I have openldap-2.4.15 with no optimisation (-O0) for the purposes of debugging. The most common backtrace I see is an assertion failure in memory.c:152. Here's an example: Program terminated with signal 6, Aborted. #0 0x00b8d402 in __kernel_vsyscall () (gdb) bt #0 0x00b8d402 in __kernel_vsyscall () #1 0x009e8d20 in raise () from /lib/libc.so.6 #2 0x009ea631 in abort () from /lib/libc.so.6 #3 0x00a20e6b in __libc_message () from /lib/libc.so.6 #4 0x00a28b16 in _int_free () from /lib/libc.so.6 #5 0x00a2c070 in free () from /lib/libc.so.6 #6 0x081d5746 in ber_memfree_x (p=0xa6809478, ctx=0x0) at memory.c:152 #7 0x081d630c in ber_bvarray_free_x (a=0x9049bb8, ctx=0x0) at memory.c:731 #8 0x081d6343 in ber_bvarray_free (a=0x9049bb8) at memory.c:741 #9 0x08079757 in attr_clean (a=0xb62d41bc) at attr.c:134 #10 0x0807983b in attrs_free (a=0xb62d41bc) at attr.c:196 #11 0x0807c059 in entry_clean (e=0xb5acfdbc) at entry.c:504 #12 0x0811ec17 in ldap_back_search (op=0xa680e5d8, rs=0xb5ad10e0) at search.c:354 #13 0x080f2b02 in overlay_op_walk (op=0xa680e5d8, rs=0xb5ad10e0, which=op_search, oi=0x8fa9208, on=0x0) at backover.c:669 #14 0x080f2d0a in over_op_func (op=0xa680e5d8, rs=0xb5ad10e0, which=op_search) at backover.c:721 #15 0x080f2dae in over_op_search (op=0xa680e5d8, rs=0xb5ad10e0) at backover.c:743 #16 0x080720d6 in fe_op_search (op=0xa680e5d8, rs=0xb5ad10e0) at search.c:366 #17 0x08071a2c in do_search (op=0xa680e5d8, rs=0xb5ad10e0) at search.c:217 #18 0x0806e705 in connection_operation (ctx=0xb5ad11d0, arg_v=0xa680e5d8) at connection.c:1097 #19 0x0806ebdf in connection_read_thread (ctx=0xb5ad11d0, argv=0x13) at connection.c:1223 #20 0x0819ecad in ldap_int_thread_pool_wrapper (xpool=0x8f86fa0) at tpool.c:663 #21 0x00b3346b in start_thread () from /lib/libpthread.so.0 #22 0x00a90dbe in clone () from /lib/libc.so.6 (gdb) I have seen quite a few of these backtraces, although sometimes coming through slap_sl_free (and a couple of other places) instead of ber_bvarray_free_x. Let me know what further information I can provide. Many thanks Toby Blake School of Informatics University of Edinburgh

1 0

SSL/TLS memory leak in multithread mode. more detail about ITS#6018
by timling2003＠gmail.com 13 Mar '09

13 Mar '09

--000e0cd291e2f684b60464fb3237 Content-Type: multipart/alternative; boundary=000e0cd291e2f6849e0464fb3235 --000e0cd291e2f6849e0464fb3235 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit The program is a daemon which will create a thread to query LDAP server for every request. a part of code of socket loop: newfd = accept(listen_fd, &cliaddr, &clilen); pthread_attr_setdetachstate(&attr, PTHREAD_CREATE_DETACHED); pthread_create(&instance_thread, &attr, queryldap, (void *)newfd); a part of code of querying LDAP server: int queryldap() { timeout = 10 ldap_set_option( NULL, LDAP_OPT_NETWORK_TIMEOUT, &timeout ); if SSL ldap_initialize(&ld, "ldaps://..."); else ldap_initialize(&ld, "ldap://..."); protocol = 3; rc = 0; if SSL or TLS ldap_set_option( ld, LDAP_OPT_PROTOCOL_VERSION, &protocol ); ldap_set_option( NULL, LDAP_OPT_X_TLS_REQUIRE_CERT, &rc ); if TLS ldap_start_tls_s( ld, NULL, NULL ); ldap_bind_s(ld, bindDN, bindPasswd, LDAP_AUTH_SIMPLE); ... ldap_unbind_s(ld); } I cannot use ldap_pvt_tls_destroy(), because this function can call only once. If I don't create different thread for every request (one thread for all request), there is no any memory leak. So, I think this case is related to the multithread mode. Maybe, there are some memory that don't be freed after the querying thread finished. In addtion, there is no any memory leak when I use unencryption mode. The attachment is the snippet of memory image which is likely the leak part. The memory leak produced by one thread seems to be about 352 bytes. --000e0cd291e2f6849e0464fb3235 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable The program is a daemon which will create a thread to query LDAP server for= every request. a part of code of socket loop: newfd =3D accept(= listen_fd, &cliaddr, &clilen); pthread_attr_setdetachstate(&= attr, PTHREAD_CREATE_DETACHED); pthread_create(&instance_thread, &attr, queryldap, (void *)newfd);<= br> a part of code of querying LDAP server: int queryldap() { = =A0=A0=A0 timeout =3D 10 =A0=A0=A0 ldap_set_option( NULL, LDAP_OPT_NETWO= RK_TIMEOUT, &timeout ); =A0=A0=A0 if SSL =A0 =A0=A0 =A0=A0 ldap_initialize(&ld, "ld= aps://..."); =A0=A0=A0 else =A0=A0=A0=A0=A0=A0=A0 ldap_initializ= e(&ld, "ldap://..."); =A0=A0=A0 protocol =3D 3; =A0= =A0=A0 rc =3D 0; =A0=A0=A0 if SSL or TLS =A0=A0=A0=A0=A0=A0=A0 ldap_s= et_option( ld, LDAP_OPT_PROTOCOL_VERSION, &protocol ); =A0 =A0=A0 =A0=A0 ldap_set_option( NULL, LDAP_OPT_X_TLS_REQUIRE_CERT, &= rc ); =A0=A0=A0 if TLS =A0=A0=A0=A0=A0=A0=A0 ldap_start_tls_s( ld= , NULL, NULL ); =A0=A0=A0 ldap_bind_s(ld,=A0 bindDN, bindPasswd, LDA= P_AUTH_SIMPLE); =A0=A0=A0 ... =A0=A0=A0 ldap_unbind_s(ld); } I cannot use ldap_pvt_tls_destroy(= ), because this function can call only once. If I don't create d= ifferent thread for every request (one thread for all request), there is no= any memory leak. So, I think this case is related to the multithread mode.= Maybe, there are some memory that don't be freed after the querying thr= ead finished. In addtion, there is no any memory leak when I use unencry= ption mode. The attachment is the snippet of memory image which is l= ikely the leak part. The memory leak produced by one thread seems to be abo= ut 352 bytes. --000e0cd291e2f6849e0464fb3235-- --000e0cd291e2f684b60464fb3237 Content-Type: application/octet-stream; name=memory-leak-snippet Content-Disposition: attachment; filename=memory-leak-snippet Content-Transfer-Encoding: base64 X-Attachment-Id: f_fs8k4pwa0 AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD///////////////// ////////////////////////////////////////////////////////////////////AAAAAAAA AAARAAAAiDkRCGAMGgh0kgAAUQEAAEkLAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA//// //////////////////////////////////////////////////////////////////////////// /////wAAAAAAAAAAEQAAAOg6EQjADRoItZIAAFEBAABOCwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAP////////////////////////////////////////////////////////////////// //////////////////8AAAAAAAAAABEAAABIPBEIIA8aCPaSAABRAQAAUwsAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAD///////////////////////////////////////////////////// ////////////////////////////////AAAAAAAAAAARAAAAqD0RCIAQGgg3kwAAUQEAAFgLAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA//////////////////////////////////////// /////////////////////////////////////////////wAAAAAAAAAAEQAAAAg/EQjgERoIeJMA AFEBAABdCwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAA= --000e0cd291e2f684b60464fb3237--

1 0

(ITS#6020) MMR sends too many redundant messages
by hyc＠OpenLDAP.org 13 Mar '09

13 Mar '09

Full_Name: Howard Chu Version: HEAD/RE24 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (76.91.220.157) Submitted by: hyc Currently syncprov knows not to send a change back to the originating server, but it will still send changes back to the server that delivered it. (E.g., server 1 replicates to server 2, server 2 to server 3. Server 3 will immediately try to send the same message back to server 2.) Syncrepl isn't providing any information for syncprov to know where a change came from. The fix is for syncrepl to attach the incoming sync_cookie state to the operation it uses when writing to its own database. Coming in HEAD shortly.

1 0

Re: (ITS#6019) puzon@eska.pl
by michael＠stroeder.com 12 Mar '09

12 Mar '09

puzon(a)eska.pl wrote: > Full_Name: Lukasz Brodowski > Version: 2.4.15 > OS: freebsd 7.1 > URL: > Submission from: (NULL) (62.29.173.121) > > > Command like this: 'ldapsearch -x -D "cn=Manager,dc=example" -H > ldap://ldap.example -W' ends segmentation fault 11 (core dumped), when I send > correct password. I use this on several machines and effect is the same. Can you obtain a stack trace with gdb and the core file? See here how to obtain it: http://www.openldap.org/faq/data/cache/59.html Ciao, Michael.

1 0

Re: (ITS#5973) Syncrepl can update more than one csn value
by hyc＠symas.com 12 Mar '09

12 Mar '09

rein(a)OpenLDAP.org wrote: > Full_Name: Rein Tollevik > Version: CVS HEAD > OS: irrelevant > URL: > Submission from: (NULL) (81.93.160.250) > Submitted by: rein > > > Syncrepl can update more than one csn value in one operation, False. An operation can only affect one entry. An entry has only one CSN (entryCSN is single-valued). Multiple changes may have occurred to an entry before a consumer sees it, but the consumer will only see the final result and only the last entryCSN. On the other hand, multiple CSNs may have changed in the cookie that is transmitted to the consumer. That's a separate issue... > but only one can > be passed to syncprov in the csn queue. > Syncprov should instead pick the > updated values from the modify operation. > > A patch that fixes this is coming. This patch depends on the ITS#5972 patch, > and is required for the new test058 to succeed. > > Rein Tollevik > Basefarm AS > > -- -- 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#5973) Syncrepl can update more than one csn value
by hyc＠symas.com 12 Mar '09

12 Mar '09

rein(a)OpenLDAP.org wrote: > Full_Name: Rein Tollevik > Version: CVS HEAD > OS: irrelevant > URL: > Submission from: (NULL) (81.93.160.250) > Submitted by: rein > > > Syncrepl can update more than one csn value in one operation, but only one can > be passed to syncprov in the csn queue. Syncprov should instead pick the > updated values from the modify operation. The syncrepl patch broke the CSN queue, which has caused out-of-order updates in test050. I have reverted it. Every write operation begins with a queued CSN and ends by graduating a CSN. You removed the enqueueing step, and so the queue contents were invalid. > A patch that fixes this is coming. This patch depends on the ITS#5972 patch, > and is required for the new test058 to succeed. test058 has the same number of errors with or without the syncrepl patch, so I don't think it was relevant to the issues you were addressing. I'm still skeptical about the syncprov half of the patch. The two patches were actually unrelated, the syncprov patch takes effect regardless of the syncrepl 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#6015) ldapsearch can not retrieve same uid that has been added after it was deleted
by michael＠stroeder.com 12 Mar '09

12 Mar '09

arun_patel(a)yahoo.com wrote: > Version: 2.2.13 In general: This is a *very* ancient release. Also there's no information about the underlying Berkeley-DB and the database backend used in your setup. It's very unlikely that anybody can help you track issues down with this setup. > 6) ldapsearch -LLL -x -b uid=tesid,xyz.com > unable to retrieve the testid (Problem) > > I know the testid is in ldap, because went thru ldap browser and did see the > entry. > [..] > I then did /etc/init.d/ldap stop and /etc/init.d/ldap start > > After entering ldapsearch -LLL -x -b uid=tesid,xyz.com, it works, > > Why does this happen? Not much information about your setup. You should provide more details (e.g. database backend used, indexing and ACLs in slapd.conf). Preferrably discuss your setup on the openldap-software mailing list. Ciao, Michael.

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs