openldap-bugs November 2007

openldap-bugs@openldap.org

44 participants
170 discussions

Re: (ITS#4860) Sets' enhancement
by jclarke＠linagora.com 09 Nov '07

09 Nov '07

This is a multi-part message in MIME format. --------------080208090603090201080004 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Pierangelo Masarati a écrit : >> The patch attached corrects this problem on RE23 and HEAD for me >> and doesn't have any side effects on our test set. However, it >> may not be the "right" way - please correct if necessary! > > It seems to work correctly, but there seems to be an easier fix: just > NULL out the pointer to lset/rset, respectively. I'm patching the > code this way, please test if you get a chance. Whoops - looks like I spoke too soon. After more testing, I've realized that the same commit this patch applied to actually changed the behaviour of the "+" operation in the slap_set_join() function when operating on empty sets, and can cause errors. The attached proposed patch restores the original design. The difference is minor, but can cause slapd to hang indefinitely on some sets, like the one in the generic example below. I understand an element in a set can have 3 possible states: 1) non-empty string (example: "cn=user,ou=people,dc=example,dc=com") 2) empty string (example: "", BER_BVISEMPTY) 3) NULL (BER_BVISNULL) Below I represent sets in {element1, element2} notation, to describe the current behaviour (in HEAD) for slap_set_join on the '+' operation: - {"One", "Two"} + {"Three", "Four"} ==> {"OneThree", "OneFour", "TwoThree", "TwoFour"} - {"One", "Two"} + {""} ==> {"One", "Two"} - {"One", "Two"} + {NULL} ==> {"One", "Two"} Consider the following set: set="[ldap:///] + [ldap:///<searchbase>??<scope>?<filter1>] + [??<scope>?<filter2>]" Assuming [ldap:///<searchbase>??<scope>?<filter1>] returns a DN, this works. However, if [ldap:///<searchbase>??<scope>?<filter1>] returns no entries, this value is NULL. Therefore, the rest of the set becomes: "[ldap:///] + {NULL} + [??<scope>?<filter2>]" ...which is handed to the '+' operation in slap_set_join, to become: [ldap:///??<scope>?<filter2>] ...which obviously isn't valid. The attached patch changes the last case of the current behaviour for slap_set_join on the '+' operation. This was already the behaviour before version 1.24.2.6 Thu Sep 13 20:43:29 2007 UTC: - {"One", "Two"} + {NULL} ==> {NULL} Thus, in the above example, the whole set would resolve to NULL, and access is not granted. Sorry for the confusion. Can this patch be integrated? Regards, Jonathan -- Jonathan Clarke Cellule OSSA - Groupe LINAGORA 27 rue de Berri, 75008 Paris Tél: 01 58 18 68 28, fax: 01 58 18 68 29 http://www.linagora.com - http://www.08000linux.com --------------080208090603090201080004 Content-Type: text/x-patch; name="jonathan-clarke-20071109.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="jonathan-clarke-20071109.patch" --- servers/slapd/sets.c.orig 2007-11-01 16:47:35.000000000 +0100 +++ servers/slapd/sets.c 2007-11-01 16:48:21.000000000 +0100 @@ -277,25 +277,13 @@ j = slap_set_size( lset ); /* handle empty set cases */ - if ( i == 0 ) { - if ( j == 0 ) { - set = cp->set_op->o_tmpcalloc( i * j + 1, sizeof( struct berval ), - cp->set_op->o_tmpmemctx ); - if ( set == NULL ) { - break; - } - BER_BVZERO( &set[ 0 ] ); - break; - - } else { - set = set_dup( cp, lset, SLAP_SET_LREF2REF( op_flags ) ); - lset = NULL; + if ( i == 0 || j == 0 ) { + set = cp->set_op->o_tmpcalloc( i * j + 1, sizeof( struct berval ), + cp->set_op->o_tmpmemctx ); + if ( set == NULL ) { break; } - - } else if ( j == 0 ) { - set = set_dup( cp, rset, SLAP_SET_RREF2REF( op_flags ) ); - rset = NULL; + BER_BVZERO( &set[ 0 ] ); break; } --------------080208090603090201080004--

1 0

RE: (ITS#5215) Use of ln is hardcoded in some files
by emmanuel.duru＠atosorigin.com 09 Nov '07

09 Nov '07

OK it works, thank you. -----Message d'origine----- De : Hallvard Breien Furuseth [mailto:h.b.furuseth@usit.uio.no] Envoyé : jeudi 8 novembre 2007 15:48 À : 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 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: [JunkMail] Re: ITS#5212 command that caused the crash
by hyc＠symas.com 08 Nov '07

08 Nov '07

Tony Earnshaw wrote: > Howard Chu skrev, on 08-11-2007 14:38: > >>> 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 > > Thank you :) I made a patch from a diff -Naur of the complete CVS > filter.c and the 2.4.6 one, incorporated it into Buchan's rpm spec file, > rebuilt the rpms, installed them and ran the same command. Guess what? > slapd2.4 doesn't report '?undefined' any more, nor crash: Right, I got tired of trying to guess what the filter was from that unhelpful diagnostic. Got rid of "?undefined" last year on Christmas (rev 1.136) and that was part of 2.4.4. This crash was an unfortunate oversight between 2.4.5 and 2.4.6... > Nov 9 06:36:56 tru slapd2.4[2576]: conn=21 fd=14 ACCEPT from > PATH=/var/run/slapd/ldapi (PATH=/var/run/slapd/ldapi) > Nov 9 06:36:56 tru slapd2.4[2576]: conn=21 op=0 BIND > dn="cn=admin,dc=billy,dc=demon,dc=nl" method=128 > Nov 9 06:36:56 tru slapd2.4[2576]: conn=21 op=0 BIND > dn="cn=admin,dc=billy,dc=demon,dc=nl" mech=SIMPLE ssf=0 > Nov 9 06:36:56 tru slapd2.4[2576]: conn=21 op=0 RESULT tag=97 err=0 text= > Nov 9 06:36:56 tru slapd2.4[2576]: conn=21 op=1 SRCH > base="dc=billy,dc=demon,dc=nl" scope=2 deref=0 filter="(?facsimileTele > phoneNumber=+4753491111)" > Nov 9 06:36:56 tru slapd2.4[2576]: conn=21 op=1 SRCH > attr=facsimileTelephoneNumber > Nov 9 06:36:56 tru slapd2.4[2576]: conn=21 op=1 SEARCH RESULT tag=101 > err=0 nentries=0 text=inappropriate matching request > Nov 9 06:36:56 tru slapd2.4[2576]: conn=21 op=2 UNBIND > Nov 9 06:36:56 tru slapd2.4[2576]: conn=21 fd=14 closed > > --Tonni -- -- 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 tonni＠hetnet.nl 08 Nov '07

08 Nov '07

Howard Chu skrev, on 08-11-2007 14:38: >> 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 Thank you :) I made a patch from a diff -Naur of the complete CVS filter.c and the 2.4.6 one, incorporated it into Buchan's rpm spec file, rebuilt the rpms, installed them and ran the same command. Guess what? slapd2.4 doesn't report '?undefined' any more, nor crash: Nov 9 06:36:56 tru slapd2.4[2576]: conn=21 fd=14 ACCEPT from PATH=/var/run/slapd/ldapi (PATH=/var/run/slapd/ldapi) Nov 9 06:36:56 tru slapd2.4[2576]: conn=21 op=0 BIND dn="cn=admin,dc=billy,dc=demon,dc=nl" method=128 Nov 9 06:36:56 tru slapd2.4[2576]: conn=21 op=0 BIND dn="cn=admin,dc=billy,dc=demon,dc=nl" mech=SIMPLE ssf=0 Nov 9 06:36:56 tru slapd2.4[2576]: conn=21 op=0 RESULT tag=97 err=0 text= Nov 9 06:36:56 tru slapd2.4[2576]: conn=21 op=1 SRCH base="dc=billy,dc=demon,dc=nl" scope=2 deref=0 filter="(?facsimileTele phoneNumber=+4753491111)" Nov 9 06:36:56 tru slapd2.4[2576]: conn=21 op=1 SRCH attr=facsimileTelephoneNumber Nov 9 06:36:56 tru slapd2.4[2576]: conn=21 op=1 SEARCH RESULT tag=101 err=0 nentries=0 text=inappropriate matching request Nov 9 06:36:56 tru slapd2.4[2576]: conn=21 op=2 UNBIND Nov 9 06:36:56 tru slapd2.4[2576]: conn=21 fd=14 closed --Tonni -- Tony Earnshaw Email: tonni at hetnet dot nl

1 0

(ITS#5226) ldapadd: invalid format (line 1) entry: ""
by babu.shanmugham＠gmail.com 08 Nov '07

08 Nov '07

Full_Name: Babu Shanmugam Version: 2.1 OS: windows URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (47.230.0.45) Hey, I am stuck u with this error....ldapadd: invalid format (line 1) entry: "".... I am not sure which file to change, either init.ldif or slapd.conf. My files contents looks like below. 1..slapd.conf. database bdb suffix "dc=mymozilla,dc=com" rootdn "cn=Manager,dc=mymozilla,dc=com" rootpw passmozilla directory C:/openldap/var/openldap-data index objectClass eq 2. init.ldif : dn: dc=mymozilla,dc=com objectClass: eq objectClass: organization objectClass: eq description: Description of your domain o: Something else about your domain dc: mymozilla When i run this command, ldapadd -x -D "cn=Manager,dc=mymozilla,dc=com" -w passmozilla -v -f init.ldif , i get the following error init.ldif ldap_initialize( <DEFAULT> ) ldapadd: invalid format (line 1) entry: "" Please let me know how to overcome this. Regards.... Babu Shanmugam

1 0

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

08 Nov '07

--On Thursday, November 08, 2007 1:01 PM -0500 "Allan E. Johannesen" <aej(a)WPI.EDU> wrote: >>>>>> "quanah" == Quanah Gibson-Mount <quanah(a)zimbra.com> writes: > > quanah> --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. > > quanah> Looks like it is related to the use of the -w flag, since your > segfault quanah> and assertions were hit when it was part of the command. > Thanks for quanah> the example bits to reproduce. > > Although the schemas probably don't come into play, and could probably be > removed from the config, I also put the two wpi schemas in > http://users.wpi.edu/~aej > > I forgot them when I was submitting. Please make sure you CC the ITS system on all emails about this bug. Thanks. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

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

← Newer
1
...
8
9
10
11
12
13
14
...
17
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 November 2007