openldap-bugs June 2009

openldap-bugs@openldap.org

41 participants
115 discussions

Start a nNew thread

Re: (ITS#5701) connection.c asserting during test008
by richton＠nbcs.rutgers.edu 23 Jun '09

23 Jun '09

The only connection issue I'm still seeing is #5733...I believe this is resolved in modern code.

1 0

(ITS#6186) sizelimit broken
by christian.fischer＠fischundfischer.com 23 Jun '09

23 Jun '09

Full_Name: Christian Fischer Version: 2.4.16 OS: gentoo amd64 URL: Submission from: (NULL) (213.221.82.34) slapd ignores sizelimit values above 500 and -1 (unlimited) If sizelimit is set to a value >=0 and <=500 the behavior is as expected, unlimited (-1) and values >500 are ignored. I've turned on args debugging to see if something is different between 2.4.16 and 2.3.43, which works for me. Version 2.3.43 op->ors_slimit is set to 0 if do_search() is executed, version 2.4.16 op->ors_slimit is set to 500 (SLAPD_DEFAULT_SIZELIMIT). That explains the different behavior of limits_check(). With ors_slimit set to SLAPD_DEFAULT_SIZELIMIT it runs into servers/slapd/limits.c:1294 and ors_slimit will only set to ors_limit->lms_s_soft if the value of ors_limit->lms_s_soft is between 1 and SLAPD_DEFAULT_SIZELIMIT -1. This patch has solved my problem for now, sizelimit statement is working without restrictions. --- openldap-2.4.16/servers/slapd_orig/limits.c 2009-01-22 01:01:01.000000000 +0100 +++ openldap-2.4.16/servers/slapd/limits.c 2009-06-15 09:27:36.212817654 +0200 @@ -1077,6 +1077,9 @@ return 0; } + /* fix sizelimit */ + op->ors_slimit = 0; + /* allow root to set no limit */ if ( be_isroot( op ) ) { op->ors_limit = NULL; ### config snippet ### include /etc/openldap/schema/core.schema include /etc/openldap/schema/cosine.schema include /etc/openldap/schema/inetorgperson.schema include /etc/openldap/schema/rfc2307bis.schema include /etc/openldap/schema/samba.schema include /etc/openldap/schema/misc.schema include /etc/openldap/schema/openssh-lpk.schema include /etc/openldap/schema/radius.schema include /etc/openldap/schema/egr.schema include /etc/openldap/schema/mozillaabpersonalpha.schema include /etc/openldap/schema/dhcp.schema pidfile /var/run/openldap/slapd.pid argsfile /var/run/openldap/slapd.args TLSCertificateFile /etc/openldap/ssl/ldap.pem TLSCertificateKeyFile /etc/openldap/ssl/ldap.pem TLSCACertificateFile /etc/openldap/ssl/ca.crt TLSVerifyClient never loglevel none serverID 2 security ssf=256 disallow bind_anon require authc database bdb suffix "dc=foo,dc=bar" rootdn "cn=Manager,dc=foo,dc=bar" rootpw secret directory /var/lib/openldap-data checkpoint 32 30 sizelimit unlimited index objectclass,entryCSN,entryUUID eq overlay syncprov syncprov-checkpoint 100 10 syncprov-sessionlog 100 syncprov-reloadhint TRUE syncrepl rid=123 provider=ldap://isc01.foo.bar starttls=yes tls_reqcert=never type=refreshAndPersist retry="5 5 60 +" searchbase="dc=foo,dc=bar" scope=sub schemachecking=on bindmethod=simple binddn="cn=syncrepl,ou=dsa,dc=foo,dc=bar" credentials=secret mirrormode on ### ACL ### # [snip]

1 0

Re: (ITS#6185) test033-glue-syncrepl failed
by richton＠nbcs.rutgers.edu 23 Jun '09

23 Jun '09

This appears to be semi-regular; I have two more substantially identical testrun directories indicating failure.

1 0

Re: ITS#6101 Uninitialized SlapReply components
by h.b.furuseth＠usit.uio.no 23 Jun '09

23 Jun '09

hyc(a)symas.com writes: > What do you mean by "components are commonly used uninitialized" ? > Have you actually seen cases where the code reads these values before > they are init'd? Certainly valgrind never trips over them. There is nothing for Valgrind to trip over if the compiler zero-fills rs.sr_un union when it sees SlapReply rs = {REP_RESULT}; However, add this in slap.h, which is all the compiler needs to emit for that initialization: #define DECL_SlapReply(name, type) \ SlapReply name; \ name.sr_type = 0; \ name.sr_tag = 0; \ name.sr_msgid = 0; \ name.sr_err = 0; \ name.sr_matched = 0;\ name.sr_text = 0; \ name.sr_ref = 0; \ name.sr_ctrls = 0; \ name.sr_un.sru_sasl.r_sasldata = 0; \ name.sr_flags = 0 Replace current initializations with that as follows: grep -l 'SlapReply[<tab> ][a-z0-9]* *=' *.c */*.c | xargs perl -i -pe ' s/^(\t+)(SlapReply)\s+(\w+)\s*=\s*{\s*(\w+)\s*}\;/$1DECL_$2($3, $4)\;/' (type ctrl-v tab in shell for the<tab>) Compile with C99 or gcc extension mode to allow mixed code and decls. make test doesn't even survive test000. And yes, valgrind is annoyed. -- Hallvard

1 0

Re: (ITS#6184) slapd segmentation fault
by michael＠stroeder.com 23 Jun '09

23 Jun '09

jginsberg(a)thehive.com wrote: > > I'm not sure I'm really comfortable with running a pre-release 2.4.16 is the currently STABLE release. You should definitely use that instead of 2.4.15. See also: http://www.openldap.org/faq/data/cache/225.html Ciao, Michael.

1 0

ITS#6101 Uninitialized SlapReply components
by hyc＠symas.com 22 Jun '09

22 Jun '09

What do you mean by "components are commonly used uninitialized" ? Have you actually seen cases where the code reads these values before they are init'd? Certainly valgrind never trips over them. -- -- 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#6170) test039 seg faults
by hyc＠symas.com 22 Jun '09

22 Jun '09

michael(a)stroeder.com wrote: > Seg faulted again. > > Take two of tests/testrun/ available under: > > http://www.stroeder.com/temp/openldap/its6170_test039-testrun2.tar.gz > > I really wonder why I have such subtle issues which are not > deterministic. Maybe it's because I'm running make test on an old laptop > with Pentium Mobile 1,8 GHz which is rather slow? > > I tested with default values SLEEP1=7 and SLEEP2=15. Even if these > values are too low for this particular system slapd should never ever > seg fault. Same trace as #5733, closing this ITS as a dup. -- -- 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#6174) Permanent high CPU Load with Multimaster
by hyc＠symas.com 22 Jun '09

22 Jun '09

Frank.Offermanns(a)caseris.de wrote: > Full_Name: Frank Offermanns > Version: 2.4.16 > OS: Windows XP/Ubuntu 9.04 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (217.6.189.242) > > > Hello everyone, > > I compiled the LDAP Version 2.4.16 from CVS at 16 June with MINGW/MSYS on > Windows. I used the latest version because every previous 2.4.16 version had > similar problems. There is no "latest 2.4.16" version. There is only one release with version number 2.4.16, whether you got it from CVS or from the web site. > I have two systems working together as multimasters. After a random time (less > than a day) it can happen, that a core of a CPU uses 100 % CPU Load. Both System > seems to be working correctly, but the High CPU Load slows down everything. > No matter how long i wait, this core stays at 100 % CPU load. > On another test a test write operation never returned and I also had the high > CPU load. After i killed my test write process, the slapd.exe crashed. (The > write procees was on a another PC) Use gdb to get traces of the active threads when the 100% CPU situation occurs. Likewise, use gdb to get traces when slapd crashes. -- -- 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#6184) slapd segmentation fault
by jginsberg＠thehive.com 22 Jun '09

22 Jun '09

Hi Quanah -- I'm not sure I'm really comfortable with running a pre-release -- this is for our corporate identity and contact management server, and it is as mission critical as that sounds. It was enough of a headache running it under production load inside gdb to get the stack trace. :-) The workaround we've employed for the timebeing is switching to the bdb backend and using monit to keep an eye on things. We'll look forward to seeing what comes out in 2.4.17 and re-evaluate then. Thanks! -jag On Jun 22, 2009, at 5:31 PM, Quanah Gibson-Mount wrote: > --On Monday, June 22, 2009 4:08 PM +0000 jginsberg(a)hostyours.com > wrote: > >> Full_Name: Joshua Ginsberg >> Version: 2.4.15 >> OS: Debian lenny 2.6.29.4 >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (208.78.90.5) > > There have been numerous fixes since 2.4.15 and 2.4.16. I suggest > you try the current CVS RE24 and see if you still have issues. > > --Quanah > > -- > > Quanah Gibson-Mount > Principal Software Engineer > Zimbra, Inc > -------------------- > Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#6184) slapd segmentation fault
by quanah＠zimbra.com 22 Jun '09

22 Jun '09

--On Monday, June 22, 2009 4:08 PM +0000 jginsberg(a)hostyours.com wrote: > Full_Name: Joshua Ginsberg > Version: 2.4.15 > OS: Debian lenny 2.6.29.4 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (208.78.90.5) There have been numerous fixes since 2.4.15 and 2.4.16. I suggest you try the current CVS RE24 and see if you still have issues. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs June 2009