- openldap-bugs - openldap.org

Re: (ITS#5225) unexpected results in slapadd
by quanah＠zimbra.com 08 Nov '07

08 Nov '07

--On Thursday, November 08, 2007 4:46 PM +0000 aej(a)wpi.edu wrote: > Full_Name: Allan E. Johannesen > Version: 2.4.6 > OS: RHEL4 i686 > URL: http://users.wpi.edu/~aej > Submission from: (NULL) (130.215.24.208) > > > Dependent on load flags (I normally have been using -w -q), I get various > results. Assertion failure, segfault, or success. Looks like it is related to the use of the -w flag, since your segfault and assertions were hit when it was part of the command. Thanks for the example bits to reproduce. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#5225) unexpected results in slapadd
by aej＠wpi.edu 08 Nov '07

08 Nov '07

Full_Name: Allan E. Johannesen Version: 2.4.6 OS: RHEL4 i686 URL: http://users.wpi.edu/~aej Submission from: (NULL) (130.215.24.208) Dependent on load flags (I normally have been using -w -q), I get various results. Assertion failure, segfault, or success. utility5:/tools/src/openldap/RHEL4-i686/openldap-2.4.6# rm /var/openldap-data/* utility5:/tools/src/openldap/RHEL4-i686/openldap-2.4.6# ln /var/openldap-bdb/DB_CONFIG /var/openldap-data/ utility5:/tools/src/openldap/RHEL4-i686/openldap-2.4.6# servers/slapd/slapadd -w -q -f /usr/local/etc/openldap/slapd.utility5.conf < users.ldapv2.2007.11.08.ldif slapadd: entry.c:760: entry_encode: Assertion `i == a->a_numvals' failed. Abort utility5:/tools/src/openldap/RHEL4-i686/openldap-2.4.6# rm /var/openldap-data/* utility5:/tools/src/openldap/RHEL4-i686/openldap-2.4.6# ln /var/openldap-bdb/DB_CONFIG /var/openldap-data/ utility5:/tools/src/openldap/RHEL4-i686/openldap-2.4.6# servers/slapd/slapadd -q -f /usr/local/etc/openldap/slapd.utility5.conf < users.ldapv2.2007.11.08.ldif utility5:/tools/src/openldap/RHEL4-i686/openldap-2.4.6# rm /var/openldap-data/* utility5:/tools/src/openldap/RHEL4-i686/openldap-2.4.6# ln /var/openldap-bdb/DB_CONFIG /var/openldap-data/ utility5:/tools/src/openldap/RHEL4-i686/openldap-2.4.6# servers/slapd/slapadd -w -f /usr/local/etc/openldap/slapd.utility5.conf < users.ldapv2.2007.11.08.ldif Segmentation fault utility5:/tools/src/openldap/RHEL4-i686/openldap-2.4.6# rm /var/openldap-data/* utility5:/tools/src/openldap/RHEL4-i686/openldap-2.4.6# ln /var/openldap-bdb/DB_CONFIG /var/openldap-data/ utility5:/tools/src/openldap/RHEL4-i686/openldap-2.4.6# servers/slapd/slapadd -f /usr/local/etc/openldap/slapd.utility5.conf < users.ldapv2.2007.11.08.ldif I've placed DB_CONFIG, users.ldapv2.2007.11.08.ldif, and slapd.utility5.conf in http://users.wpi.edu/~aej/

1 0

Re: (ITS#5187) test020-proxycache failing in RE_2_4
by rhafer＠suse.de 08 Nov '07

08 Nov '07

On Donnerstag, 8. November 2007, you wrote: > <quote who="Ralf Haferkamp"> > > > On Donnerstag, 8. November 2007, rhafer(a)suse.de wrote: > >> I think I found a way. > >> 1. The SLAPD_ABANDON/op->o_abandon part of the cleanup handler will now > >> only get executed if the final result for the search has not been > >> received > >> (caching_reason == PC_IGNORE). > >> 2. Additionally, to add the entries to the cache, I do no longer use the > >> original Connection Object but create a new one > >> (connection_fake_init()), > >> because the op->o_abandon will be set for the original connection as > >> soon > >> as the client closes it. > >> > >> I'll do some more testing locally an submit this to HEAD later for more > >> external testing. > > > > Fix submitted to HEAD. Please test (preferably on the machine that caused > > this > > test to fail most often ;) ). > > I'll try this tonight. > > Just to clarify, this is a fix in the code, rather than the test, which I > thought Howard had changed? Yes, it is a fix in the pcache code. The fix in the testcase was only done temporarely in the RE24 branch (HEAD was not changed). I intend to remove it as soon as I get positive feedback. -- Ralf

1 0

Re: (ITS#5187) test020-proxycache failing in RE_2_4
by ghenry＠OpenLDAP.org 08 Nov '07

08 Nov '07

<quote who="Ralf Haferkamp"> > On Donnerstag, 8. November 2007, rhafer(a)suse.de wrote: >> I think I found a way. >> 1. The SLAPD_ABANDON/op->o_abandon part of the cleanup handler will now >> only get executed if the final result for the search has not been >> received >> (caching_reason == PC_IGNORE). >> 2. Additionally, to add the entries to the cache, I do no longer use the >> original Connection Object but create a new one >> (connection_fake_init()), >> because the op->o_abandon will be set for the original connection as >> soon >> as the client closes it. >> >> I'll do some more testing locally an submit this to HEAD later for more >> external testing. > Fix submitted to HEAD. Please test (preferably on the machine that caused > this > test to fail most often ;) ). I'll try this tonight. Just to clarify, this is a fix in the code, rather than the test, which I thought Howard had changed? > > -- > Ralf >

1 0

Re: (ITS#5187) test020-proxycache failing in RE_2_4
by rhafer＠suse.de 08 Nov '07

08 Nov '07

On Donnerstag, 8. November 2007, rhafer(a)suse.de wrote: > I think I found a way. > 1. The SLAPD_ABANDON/op->o_abandon part of the cleanup handler will now > only get executed if the final result for the search has not been received > (caching_reason == PC_IGNORE). > 2. Additionally, to add the entries to the cache, I do no longer use the > original Connection Object but create a new one (connection_fake_init()), > because the op->o_abandon will be set for the original connection as soon > as the client closes it. > > I'll do some more testing locally an submit this to HEAD later for more > external testing. Fix submitted to HEAD. Please test (preferably on the machine that caused this test to fail most often ;) ). -- Ralf

1 0

RE: (ITS#5215) Use of ln is hardcoded in some files
by h.b.furuseth＠usit.uio.no 08 Nov '07

08 Nov '07

emmanuel.duru(a)atosorigin.com writes: > Then with MSYS, I get an error when running make on servers/slapd > Makefile: in case there is no extra LDFLAG, (...) Try this patch: --- servers/slapd/Makefile.in~ 2007-02-14 16:59:43.000000000 +0100 +++ servers/slapd/Makefile.in 2007-11-08 15:40:32.475898000 +0100 @@ -157,3 +157,3 @@ slapd.def: libbackends.a liboverlays.a version.o - @for i in $(LDFLAGS) ; do \ + @for i in XX $(LDFLAGS) ; do \ path=`expr "$$i" : "-L$.*$"`; \ @@ -169,3 +169,4 @@ base=`expr "$$i" : "-l$.*$"`; \ - for p in $$paths ; do \ + for p in " " $$paths ; do \ + test "x$$p" = "x " && continue ; \ for ext in la dll dll.a a ; do \ -- Regards, Hallvard

1 0

Re: ITS#5212 command that caused the crash
by hyc＠symas.com 08 Nov '07

08 Nov '07

tonni(a)hetnet.nl wrote: > Howard Chu skrev, on 07-11-2007 04:14: >> That's all we needed. Fixed now in HEAD. > > Do you happen to have a patch handy? I don't feel like waiting for > 2.4.7, this is the only serious bug I've found to date with 2.4.6. http://www.openldap.org/lists/openldap-commit/200711/msg00010.html -- -- Howard Chu Chief Architect, 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#5215) Use of ln is hardcoded in some files
by emmanuel.duru＠atosorigin.com 08 Nov '07

08 Nov '07

OK, forget about my remark on Cygwin/MinGW. However, you should update the "Porting OpenLDAP" FAQ to mention MSYS. Then with MSYS, I get an error when running make on servers/slapd Makefile: in case there is no extra LDFLAG, the lines @for i in $(LDFLAGS) ; do \ path=`expr "$$i" : "-L$.*$"`; \ if test $$? != 0; then continue; fi; \ paths="$$paths $$path"; \ done; \ cause a sh error: "syntax error near unexpected token ';'" -----Message d'origine----- De : Howard Chu [mailto:hyc@symas.com] Envoyé : mercredi 7 novembre 2007 04:08 À : emmanuel.duru(a)atosorigin.com Cc : openldap-its(a)openldap.org Objet : Re: (ITS#5215) Use of ln is hardcoded in some files emmanuel.duru(a)atosorigin.com wrote: > Full_Name: Emmanuel Duru > Version: 2.3.38 > OS: Windows > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (195.68.44.148) > > > configure allows the use of "cp" instead of "ln", but the build/shtool tool uses > a hardcoded "ln" (line 1266). > Some makefiles (libraries/liblunicode, libraries/libldap_r and > servers/slapd/back-hdb) use a hardcoded "-s" option. This is a problem on > Windows because in cygwin environment "cp -s" behaves the same way as "ln -s". > The use of "ln" is not welcome here because it creates a Windows shortcut, which > is not understood by mingw compiler. We only support the MSYS build environment on Windows. If you'd like to submit a patch to address this issue that doesn't break the other platforms, we can look at incorporating it. -- -- Howard Chu Chief Architect, 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#5187) test020-proxycache failing in RE_2_4
by rhafer＠suse.de 08 Nov '07

08 Nov '07

On Dienstag, 6. November 2007, rhafer(a)suse.de wrote: > I think I have an idea what causes this bug. It is possible that the client > closes the connection before the server had a chance to run the cleanup > handler, the server sets op->o_abandon then (in connection_closing()). And > after that the cleanup handler is started, which in case of op->o_abandon > does not store the results in the cache. > > To make this race more reproduceable it is sufficient to insert a > usleep(100) before the call to slap_cleanup_play() in send_ldap_response() > in result.c. > > Any suggestions for possible ways to fix this? I think I found a way. 1. The SLAPD_ABANDON/op->o_abandon part of the cleanup handler will now only get executed if the final result for the search has not been received (caching_reason == PC_IGNORE). 2. Additionally, to add the entries to the cache, I do no longer use the original Connection Object but create a new one (connection_fake_init()), because the op->o_abandon will be set for the original connection as soon as the client closes it. I'll do some more testing locally an submit this to HEAD later for more external testing. -- Ralf

1 0

Re: ITS#5212 command that caused the crash
by tonni＠hetnet.nl 07 Nov '07

07 Nov '07

Howard Chu skrev, on 07-11-2007 04:14: >> > That's all very interesting, but you haven't provided the standard >> > items needed in a crash report - a stack trace from the crash, >> >> Yes I have, but later than your reply on the ITS site. >> >> > and the actual client command that caused the crash. Also, the slapd >> > configuration, plus any relevant schema if you've used any custom >> > schema in relation to this failing command. >> >> Other details: >> >> Command: >> >> ldapsearch2.4 -x -D "cn=admin,dc=billy,dc=demon,dc=nl" -w secret >> 'facsimileTelephoneNumber=+4753491111' facsimile TelephoneNumber > > That's all we needed. Fixed now in HEAD. Do you happen to have a patch handy? I don't feel like waiting for 2.4.7, this is the only serious bug I've found to date with 2.4.6. ..Tonni -- Tony Earnshaw Email: tonni at hetnet dot nl

1 0

Re: (ITS#5224) liblber Makefile misses some libraries
by richton＠nbcs.rutgers.edu 07 Nov '07

07 Nov '07

Note for reference, shutdown() is not called directly but rather via autoconf tcp_close() macro.

1 0

Re: (ITS#5216) Dynamic Lists doc contribution to the admin guide
by ghenry＠suretecsystems.com 07 Nov '07

07 Nov '07

Is the disclaimer ok? Can I commit the patch?

1 0

Re: (ITS#5217) refint overlay doc contribution
by ghenry＠suretecsystems.com 07 Nov '07

07 Nov '07

Is the disclaimer ok? Can I commit the patch?

1 0

Re: (ITS#5223) Minor patch to replication docs
by ghenry＠suretecsystems.com 07 Nov '07

07 Nov '07

<quote who="joshua(a)itsecureadmin.com"> > Full_Name: Josh miller > Version: 2.4.6 > OS: Linux (x86) > URL: http://itsecureadmin.com/replication-doc.patch > Submission from: (NULL) (198.134.96.8) > > > Minor grammatical error in replication.sdf (replace you with sure). > > Text: > "You also need to make you the rid of each mirror node pair is different > and > that the provider syncrepl directive points to the other mirror pair." > > Please see patch at: > > http://itsecureadmin.com/replication-doc.patch > > Thanks, > Josh > Thanks. This should also say "points to the other mirror node in the pair." I've got a nice diagram for this too, which I'll commit soon. Kurt, if I just make this change myself, do we need the usual contribution waver etc.?

1 0

(ITS#5224) liblber Makefile misses some libraries
by richton＠nbcs.rutgers.edu 07 Nov '07

07 Nov '07

Full_Name: Aaron Richton Version: RE23/RE24/HEAD OS: Solaris 9 URL: Submission from: (NULL) (128.6.31.135) Noticed that liblber uses shutdown(3socket) but does not link -lsocket on Solaris. Propose adding UNIX_LINK_LIBS = $(AC_LIBS) to libraries/liblber/Makefile.in. Verified to compile with this change on Solaris and Fedora...

1 0

(ITS#5223) Minor patch to replication docs
by joshua＠itsecureadmin.com 07 Nov '07

07 Nov '07

Full_Name: Josh miller Version: 2.4.6 OS: Linux (x86) URL: http://itsecureadmin.com/replication-doc.patch Submission from: (NULL) (198.134.96.8) Minor grammatical error in replication.sdf (replace you with sure). Text: "You also need to make you the rid of each mirror node pair is different and that the provider syncrepl directive points to the other mirror pair." Please see patch at: http://itsecureadmin.com/replication-doc.patch Thanks, Josh

1 0

Re: (ITS#5214) Compilation error with a non C++ compiler
by kurt＠OpenLDAP.org 07 Nov '07

07 Nov '07

On Nov 7, 2007, at 11:21 AM, h.b.furuseth(a)usit.uio.no wrote: > h.b.furuseth(a)usit.uio.no writes: >> It has been fixed in OpenLDAP 2.3.39. > > Hmm, not mentioned in openldap-2.3.39/CHANGES. > Can add it "retroactively", I guess. That's what was done in the past. -- Kurt

1 0

Re: (ITS#5214) Compilation error with a non C++ compiler
by h.b.furuseth＠usit.uio.no 07 Nov '07

07 Nov '07

h.b.furuseth(a)usit.uio.no writes: > It has been fixed in OpenLDAP 2.3.39. Hmm, not mentioned in openldap-2.3.39/CHANGES. Can add it "retroactively", I guess. -- Regards, Hallvard

1 0

Re: (ITS#5222) Missing PDF manual for 2.4
by kurt＠OpenLDAP.org 07 Nov '07

07 Nov '07

On Nov 7, 2007, at 6:45 AM, rwiker(a)gmail.com wrote: > Full_Name: Raymond Wiker > Version: > OS: > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (143.97.2.35) > > > Just tried to download the PDF manual > (http://www.openldap.org/doc/admin24/guide.pdf) from > http://www.openldap.org/doc/index.html. This didn't work; the obvious > explanation is that the file is not there, or that it has a > different name. Now fixed. Thanks for the report. (This was due to a change in the doc/guide/Makefile which caused the rule to build guide.pdf not to build guide.pdf. I've committed changes to HEAD to address this issue.)

1 0

(ITS#5222) Missing PDF manual for 2.4
by rwiker＠gmail.com 07 Nov '07

07 Nov '07

Full_Name: Raymond Wiker Version: OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (143.97.2.35) Just tried to download the PDF manual (http://www.openldap.org/doc/admin24/guide.pdf) from http://www.openldap.org/doc/index.html. This didn't work; the obvious explanation is that the file is not there, or that it has a different name.

1 0

(ITS#5221) cache? of parent failes for hdb
by Dan.Oscarsson＠tietoenator.com 07 Nov '07

07 Nov '07

Full_Name: Dan Oscarsson Version: 2.3.32 OS: SLES 10 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (193.15.240.60) I have found that using hdb there is a bug that now prevents me from moving from my old commercial X.500 database to openldap. I need to use hdb as I move objects using rename. I am running openldap under SLES 10. The version there is 2.3.32 but I have compiled 2.3.38 and tried that too. Both have same bug. Also compiled and tried openldap-2.4.5beta. Same failure there too. I am using hdb as database. What I do is to run a job that moves around a lot of leaf nodes to other branches, sometimes creating new branches before moving the leaf node there. The job moves about 7000 nodes out of 20000 when the bug occurs. After having run this, some nodes cannot be found by searching starting at a subtree under database suffix. I have done a simple test program to see if the bug appears. It does two searches: 1) Search with search base = database suffix 2) Search with search base = a branch 2 nodes deep below database suffix. If everything is correct, same number of objects should be found. My tests show: - running test: ok - running job that moves nodes - running test: failes, many objects are missing in search starting at search base that is 2 nodes below database suffix. - stopping and starting slapd - running test again: ok >From this I suspect that it is the cache of which parent node belongs to that gets corrupted. Or can it be something else? What more could I do to trace down the bug? I do not know if the above information is enough for you to find what is wrong? Cannot include data as it contains company internal information and a simple test program did not give the same error. I have looked at the code, but it takes some time to understand it when doing it for the first time. maybe som debugging code could be added find the place where the bug is.

1 0

Re: (ITS#5146) slapo-ppolicy
by hyc＠symas.com 06 Nov '07

06 Nov '07

We can check that an incoming modification will not leave an entry with more than one userPassword value. We already have a partial check for this now. But what can we do for an entry that already had multiple values, e.g., created before the overlay was in use? Simply refuse to Bind? -- -- Howard Chu Chief Architect, 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#5200) Wrong maxderefdepth doc or default
by hyc＠symas.com 06 Nov '07

06 Nov '07

h.b.furuseth(a)usit.uio.no wrote: > Full_Name: Hallvard B Furuseth > Version: HEAD, RE23, RE24 > OS: > URL: > Submission from: (NULL) (129.240.6.233) > Submitted by: hallvard > slapd.conf(5) and slapd-config(5) say MaxDerefDepth defaults to 1, but > include/ldap_defaults.h says #define SLAPD_DEFAULT_MAXDEREFDEPTH 15. Seems it was wrong ever since it was checked in for ITS#1749. Oh well. Fixed in HEAD. -- -- Howard Chu Chief Architect, 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#5212 command that caused the crash
by hyc＠symas.com 06 Nov '07

06 Nov '07

tonni(a)hetnet.nl wrote: > > That's all very interesting, but you haven't provided the standard > > items needed in a crash report - a stack trace from the crash, > > Yes I have, but later than your reply on the ITS site. > > > and the actual client command that caused the crash. Also, the slapd > > configuration, plus any relevant schema if you've used any custom > > schema in relation to this failing command. > > Other details: > > Command: > > ldapsearch2.4 -x -D "cn=admin,dc=billy,dc=demon,dc=nl" -w secret > 'facsimileTelephoneNumber=+4753491111' facsimile TelephoneNumber That's all we needed. Fixed now in HEAD. -- -- Howard Chu Chief Architect, 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#5215) Use of ln is hardcoded in some files
by hyc＠symas.com 06 Nov '07

06 Nov '07

emmanuel.duru(a)atosorigin.com wrote: > Full_Name: Emmanuel Duru > Version: 2.3.38 > OS: Windows > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (195.68.44.148) > > > configure allows the use of "cp" instead of "ln", but the build/shtool tool uses > a hardcoded "ln" (line 1266). > Some makefiles (libraries/liblunicode, libraries/libldap_r and > servers/slapd/back-hdb) use a hardcoded "-s" option. This is a problem on > Windows because in cygwin environment "cp -s" behaves the same way as "ln -s". > The use of "ln" is not welcome here because it creates a Windows shortcut, which > is not understood by mingw compiler. We only support the MSYS build environment on Windows. If you'd like to submit a patch to address this issue that doesn't break the other platforms, we can look at incorporating it. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs