openldap-bugs January 2009

openldap-bugs@openldap.org

50 participants
201 discussions

Re: (ITS#5894) test039 fails: ldap_back_conn_delete: Assertion
by quanah＠zimbra.com 20 Jan '09

20 Jan '09

--On Saturday, January 17, 2009 3:25 PM +0000 michael(a)stroeder.com wrote: > Howard Chu wrote: >> michael(a)stroeder.com wrote: >>> Full_Name: Michael Str?der >>> Version: HEAD >>> OS: Linux >>> URL: ftp://ftp.openldap.org/incoming/ >>> Submission from: (NULL) (84.163.100.169) >>> >>> >>> lt-slapd: bind.c:157: ldap_back_conn_delete: Assertion >>> `!(*(&((lc))->lc_lcflags) >>> & (((0x00000020U))))' failed. >> >> I'm not seeing that here. Ran into a couple other problems though, fixed >> now in HEAD. Please re-test... > > Now test008 hangs... Multiple runs of test008 work for me, using BDB 4.7.25 with all 3 patches, and HEAD CVS as of 1/20/2009 @ 12:00 PST. Did you fully rebuild OpenLDAP after the latest commits? What version of BDB are you using? Is it fully patched? What backend was it using when it hung? Did you get a backtrace of where it hung? --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

ITS#5789 using IP address in CN with GnuTLS
by hyc＠symas.com 20 Jan '09

20 Jan '09

Upon further re-reading of RFC4513 and RFC2818, I think the original behavior was correct. An IP address is only allowed to match an IP Address subjectAltName, it is not allowed to match the certificate CN. -- -- 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#5860) slapd memeory leak under openldap 2.4
by rlvcosta＠yahoo.com 19 Jan '09

19 Jan '09

Pierangelo, Executing some test I'm not sure anymore if this is really a memory leakage or if some cache issue. I decided to install CentOS5.2 where I could have OpenLdap 2.3.27 compiled by the distribution and then execute more tests to check if some library in RHEL4 would be causing some problem. I then use a similar slapd.conf as in my original e-mail just without explicitly define an size for cache and idlcache there. My DB_CONFIG file has a cache defined as 50MB what is respected. Looking at some other ITS I found the ITS#3938 what I believe is very similar to my problem. I still have a DB with 3882998 entrances and where the DB files at disk is around 15GB. My machine has 12GB of memory where for sure all the DB cannot be cached into memory. In any case what is happening is that every time a transaction is done with OpenLdap, even a distribution formal compilation, the cache continues to grow until consumes all memory. If the DB is bigger than machine memory then soon or later a memory out of range will happen. The cache is never release by OpenLdap and then if a sequential search is done and since DB is bigger than memory we can speed up the problem. I also used Valgrind where I obtained : ==4963== LEAK SUMMARY: ==4963== definitely lost: 0 bytes in 0 blocks. ==4963== possibly lost: 0 bytes in 0 blocks. ==4963== still reachable: 336,091 bytes in 12,547 blocks. ==4963== suppressed: 0 bytes in 0 blocks. ==4963== Reachable blocks (those to which a pointer was found) are not shown. ==4963== To see them, rerun with: --show-reachable=yes [root@brtldp12 bdbBackupContent]# ==4964== Conditional jump or move depends on uninitialised value(s) ... Valgrind's memory management: out of memory: newSuperblock's request for 1048576 bytes failed. 2952183808 bytes have already been allocated. Valgrind cannot continue. Sorry. See it consume all the available memory and then could not allocate more memory. I also have an old version of OpenLdap in other machine with the same HW where the same DB has even more entrances. I'm trying to upgrade the OpenLdap to improve other itens but this appears to not be possible. At this old version I do not have this infinite cache problem and the only memory consumed is the Berkeley DB cache defined as 50MB. I could ldapsearch all the DB but once cache is allocated it never release it. At top I can see the memory continues associated with slapd process even the ldapsearch ends. Then if we start other ldapsearch then memory continues to be allocated. For information the old version informations is : openldap 2.1.30 and BerkeleyDB 4.2.52 With this version above I have a DB bigger than the available memory and I do not have this cache problem. I also do not have entrances like idelcache or anything else at slapd.conf file. At this way at new versions if for some reason you have a file DB bigger than your available memory with time you will have problems with OpenLdap. I will try again to force the idlcache and openldap cache but the last time tried this did not work. In this way I would identify better this problem and ask if you see this is as a bug or if some configuration would "force" openldap to cache(clean it) only using certain maximum size? Regards, Rodrigo. --- On Tue, 12/30/08, Pierangelo Masarati <ando(a)sys-net.it> wrote: > From: Pierangelo Masarati <ando(a)sys-net.it> > Subject: Re: (ITS#5860) slapd memeory leak under openldap 2.4 > To: rlvcosta(a)yahoo.com > Cc: openldap-its(a)openldap.org > Date: Tuesday, December 30, 2008, 2:06 PM > rlvcosta(a)yahoo.com wrote: > > --0-1358063323-1230648878=:64021 > > Content-Type: text/plain; charset=iso-8859-1 > > Content-Transfer-Encoding: quoted-printable > > > > Pierangelo, > > > > I could run the valgrind but at this time I do not > have the DB with the aro= > > und 4 million subscribers. In this condition, with a > small number of users,= > > I already could see some "definitive" > memory leaks and I believe they are = > > associated with OpenLdap. > > > > Just for a history I already compiled the openldap > 2.4.11 souce code withou= > > t modules and TLS since many lists make reference to > some possible issues i= > > n RHEL with TLS. Even so I could not have a load > without the possible memor= > > y leak. > > > > So I do not believe the problems are in the RHEL > libtool or glibc. > > > > In any case the result for the valgrind is (short > number of entrances at th= > > is time): > > You probably need to use an unstripped binary in order to > find out where mallocs/frees occur. Most of the occurrences > you notice are either one-time leaks. Moreover, 2.4.13 is > out, and it might have fixed some. I suggest you further > investigate using the latest code, using an unstripped > binary. > > p. > > > Ing. Pierangelo Masarati > OpenLDAP Core Team > > SysNet s.r.l. > via Dossi, 8 - 27100 Pavia - ITALIA > http://www.sys-net.it > ----------------------------------- > Office: +39 02 23998309 > Mobile: +39 333 4963172 > Fax: +39 0382 476497 > Email: ando(a)sys-net.it > -----------------------------------

1 0

Re: (ITS#5895) Example in constraint manual and documentation
by gavin.henry＠gmail.com 19 Jan '09

19 Jan '09

Sorry, I presume this was a bug in the code and the docs document the right behaviour? I'll revert them when you've confirmed. On 19/01/2009, ando(a)sys-net.it <ando(a)sys-net.it> wrote: > marjan.blatnik(a)gov.si wrote: >> Full_Name: Marjan Blatnik >> Version: 2.4.13 >> OS: Debian GNU/Linux >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (193.2.236.13) >> >> >> Example in slapo-constraint manual is not precise. >> The line >> constraint_attribute mail regex ^[:alnum:]+@mydomain.com$ >> should be >> constraint_attribute mail regex ^[[:alnum:]]+@mydomain.com$ >> >> And similar in >> http://www.openldap.org/doc/admin24/overlays.html#Constraints > > This is already fixed in HEAD, but apparently has not been ported to > 2.4. Thanks for noticing it. > > p. > > > Ing. Pierangelo Masarati > OpenLDAP Core Team > > SysNet s.r.l. > via Dossi, 8 - 27100 Pavia - ITALIA > http://www.sys-net.it > ----------------------------------- > Office: +39 02 23998309 > Mobile: +39 333 4963172 > Fax: +39 0382 476497 > Email: ando(a)sys-net.it > ----------------------------------- > > > -- Sent from my mobile device http://www.suretecsystems.com/services/openldap/

1 0

Re: (ITS#5895) Example in constraint manual and documentation
by ghenry＠OpenLDAP.org 19 Jan '09

19 Jan '09

----- "marjan blatnik" <marjan.blatnik(a)gov.si> wrote: > Full_Name: Marjan Blatnik > Version: 2.4.13 > OS: Debian GNU/Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (193.2.236.13) > > > Example in slapo-constraint manual is not precise. > The line > constraint_attribute mail regex ^[:alnum:]+@mydomain.com$ > should be > constraint_attribute mail regex ^[[:alnum:]]+@mydomain.com$ > > And similar in > http://www.openldap.org/doc/admin24/overlays.html#Constraints Thanks, updated. -- Kind Regards, Gavin Henry. OpenLDAP Engineering Team. E ghenry(a)OpenLDAP.org Community developed LDAP software. http://www.openldap.org/project/

1 0

(ITS#5897) trailing characters in olcserverids after conversion
by oliver＠itc.li 19 Jan '09

19 Jan '09

Full_Name: Oliver Liebel Version: 2.4.13 OS: opensuse 11 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (80.144.97.81) using openldap 2.4.13 (compiled from openldap.org source-package) i have noticed the following, reproducable behaviour when converting a slapd.conf to slapd.d: if slapd.conf contains serverids with ldap-urls, e.g. in this format: ServerID 1 "ldap://ldapmaster.local.site:9000" ServerID 2 "ldap://ldapslave.local.site:9000" the olcserverids in cn=config.ldif always contains some trailing (garbage) characters after the conversion, and are base64 encoded. when i set them manually in cn=config with ldapmodify, they are displayed "clean". the serverid-lines in slapd.conf are "clean" (they contain no whitespaces / tabs at the end of the line or similar, invisible characters). i have tested it several times, without using \"\ in the string and/or without portnumber. i have tested the conversion with both slaptest and slapd, in virtual and real machines, result was always the same. greetings, oliver

1 0

Re: (ITS#5880) back-bdb segfault
by michael＠stroeder.com 19 Jan '09

19 Jan '09

quanah(a)zimbra.com wrote: > --On Saturday, January 17, 2009 2:38 AM +0000 jwm(a)horde.net wrote: > >> On Fri, Jan 16, 2009 at 06:14:01PM -0800, Quanah Gibson-Mount wrote: >>> --On Saturday, January 17, 2009 2:08 AM +0000 jwm(a)horde.net wrote: >>>> RE24 as of 13 January 2009 is still crashing, sometimes due to an >>>> assertion failure and sometimes due to a segfault when manipulating the >>>> back-bdb cache. >>> Well, I'm not sure I'd use RE24 CVS right now. There's a lot of pending >>> fixes that I'll be doing soon to go into it. >> So your recommendation would be... to revert to 2.4.13 and wait for these >> fixes to land in RE24 to see if they fix the back-bdb cache-related >> segfaults I'm reporting in this ITS? > > I'm just warning that current RE24 is not expected to be at all stable. I vaguely remember a discussion about deprecating back-bdb in favor of back-hdb anyway. Ciao, Michael.

1 0

Re: (ITS#5895) Example in constraint manual and documentation
by ando＠sys-net.it 19 Jan '09

19 Jan '09

marjan.blatnik(a)gov.si wrote: > Full_Name: Marjan Blatnik > Version: 2.4.13 > OS: Debian GNU/Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (193.2.236.13) > > > Example in slapo-constraint manual is not precise. > The line > constraint_attribute mail regex ^[:alnum:]+@mydomain.com$ > should be > constraint_attribute mail regex ^[[:alnum:]]+@mydomain.com$ > > And similar in http://www.openldap.org/doc/admin24/overlays.html#Constraints This is already fixed in HEAD, but apparently has not been ported to 2.4. Thanks for noticing it. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

(ITS#5896) search error on ldap_search_ext_s
by eduard.budulea＠axigen.com 19 Jan '09

19 Jan '09

Full_Name: Eduard Budulea Version: 2.4.11 OS: gnu/linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (193.230.245.6) ldap_search_ext_s does not return all the messages that the server sends. If the response from the ldap server is compose from 2 messages: - a LDAP Intermediate Response Message - a SearchResultDone Message the ldap_search_ext_s returns only the intermediate one. Step to reporduce: have a ldap running with some entries. have a the syncprov overlay deploy. make a synchronous search with a null cookie and a filter that does not match all the entries. now modify an entry that is not in the previous result set. make another synchronous search with the cookie from the previous search. you will be able to see only the intermediate and not the done (that holds the cookie). If you do the same but using ldap_search_ext and ldap_result you will get the result done message also.

1 0

(ITS#5895) Example in constraint manual and documentation
by marjan.blatnik＠gov.si 19 Jan '09

19 Jan '09

Full_Name: Marjan Blatnik Version: 2.4.13 OS: Debian GNU/Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (193.2.236.13) Example in slapo-constraint manual is not precise. The line constraint_attribute mail regex ^[:alnum:]+@mydomain.com$ should be constraint_attribute mail regex ^[[:alnum:]]+@mydomain.com$ And similar in http://www.openldap.org/doc/admin24/overlays.html#Constraints

1 0

← Newer
1
...
12
13
14
15
16
17
18
...
21
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs January 2009