openldap-bugs

openldap-bugs@openldap.org

1 participants
20962 discussions

Re: (ITS#5348) slapcat on 2.3.38 to slapadd on 2.4.7 causes abort.
by h.b.furuseth＠usit.uio.no 01 Feb '08

01 Feb '08

Pierangelo Masarati writes: > Well, AFAIR, normalize should be called AFTER validate; and validate > should reject that CSN. The assert() was to make sure that, during > development, normalize was not called with invalid data. I'm looking at > that. Sounds like we need a macro a la #ifdef LDAP_DEVEL /* for tested non-release versions */ #define ASSERT_DEVEL assert #else #define ASSERT_DEVEL(expr) ((void)0) #endif -- Hallvard

1 0

Re: (ITS#5348) slapcat on 2.3.38 to slapadd on 2.4.7 causes abort.
by ando＠sys-net.it 01 Feb '08

01 Feb '08

Gavin Henry wrote: > <quote who="ando(a)sys-net.it"> >> hachi(a)kuiki.net wrote: >>> Tested against both HEAD and OPENLDAP_REL_ENG_2_4, same error: >>> >>> slapadd: schema_init.c:3669: csnNormalize: Assertion `val->bv_len == >>> (sizeof("YYYYmmddHHMMSS.uuuuuuZ#SSSSSS#SID#ssssss")-1)' failed. >> That assert() was added to trap incorrect values, since they should >> never happen run-time. Of course, this is not the case when >> slapadd'ing, since bulk loading can (and must be able to) include >> operational attrs like entryCSN. In any case, the value you're trying >> to slapadd, "2003061105:33:44Z#0x0003#0#0000", is invalid, and >> (probably, AFAIK) has never been in use with OpenLDAP software. When >> bulk-adding data, you should make sure it is reasonably acceptable. >> > > But isn't this a slapcat from 2.3.38? But that CSN was not CREATED by 2.3.38, only merely stored by it (probably via slapadd). 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 Email: pierangelo.masarati(a)sys-net.it ---------------------------------------

1 0

Re: (ITS#5348) slapcat on 2.3.38 to slapadd on 2.4.7 causes abort.
by ando＠sys-net.it 01 Feb '08

01 Feb '08

h.b.furuseth(a)usit.uio.no wrote: > ando(a)sys-net.it writes: >>> slapadd: schema_init.c:3669: csnNormalize: Assertion `val->bv_len == >>> (sizeof("YYYYmmddHHMMSS.uuuuuuZ#SSSSSS#SID#ssssss")-1)' failed. >> That assert() was added to trap incorrect values, since they should >> never happen run-time. > > Bad idea. slapd crashes if you search for "(entryCSN=the csn below)". Well, AFAIR, normalize should be called AFTER validate; and validate should reject that CSN. The assert() was to make sure that, during development, normalize was not called with invalid data. I'm looking at that. 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 Email: pierangelo.masarati(a)sys-net.it ---------------------------------------

1 0

Re: (ITS#5348) slapcat on 2.3.38 to slapadd on 2.4.7 causes abort.
by h.b.furuseth＠usit.uio.no 01 Feb '08

01 Feb '08

ando(a)sys-net.it writes: >> slapadd: schema_init.c:3669: csnNormalize: Assertion `val->bv_len == >> (sizeof("YYYYmmddHHMMSS.uuuuuuZ#SSSSSS#SID#ssssss")-1)' failed. > > That assert() was added to trap incorrect values, since they should > never happen run-time. Bad idea. slapd crashes if you search for "(entryCSN=the csn below)". > Of course, this is not the case when > slapadd'ing, since bulk loading can (and must be able to) include > operational attrs like entryCSN. In any case, the value you're trying > to slapadd, "2003061105:33:44Z#0x0003#0#0000", is invalid, and -- Hallvard

1 0

Re: (ITS#5348) slapcat on 2.3.38 to slapadd on 2.4.7 causes abort.
by ghenry＠OpenLDAP.org 01 Feb '08

01 Feb '08

<quote who="ando(a)sys-net.it"> > hachi(a)kuiki.net wrote: >> Tested against both HEAD and OPENLDAP_REL_ENG_2_4, same error: >> >> slapadd: schema_init.c:3669: csnNormalize: Assertion `val->bv_len == >> (sizeof("YYYYmmddHHMMSS.uuuuuuZ#SSSSSS#SID#ssssss")-1)' failed. > > That assert() was added to trap incorrect values, since they should > never happen run-time. Of course, this is not the case when > slapadd'ing, since bulk loading can (and must be able to) include > operational attrs like entryCSN. In any case, the value you're trying > to slapadd, "2003061105:33:44Z#0x0003#0#0000", is invalid, and > (probably, AFAIK) has never been in use with OpenLDAP software. When > bulk-adding data, you should make sure it is reasonably acceptable. > But isn't this a slapcat from 2.3.38?

1 0

Re: (ITS#5348) slapcat on 2.3.38 to slapadd on 2.4.7 causes abort.
by ando＠sys-net.it 01 Feb '08

01 Feb '08

hachi(a)kuiki.net wrote: > Tested against both HEAD and OPENLDAP_REL_ENG_2_4, same error: > > slapadd: schema_init.c:3669: csnNormalize: Assertion `val->bv_len == > (sizeof("YYYYmmddHHMMSS.uuuuuuZ#SSSSSS#SID#ssssss")-1)' failed. That assert() was added to trap incorrect values, since they should never happen run-time. Of course, this is not the case when slapadd'ing, since bulk loading can (and must be able to) include operational attrs like entryCSN. In any case, the value you're trying to slapadd, "2003061105:33:44Z#0x0003#0#0000", is invalid, and (probably, AFAIK) has never been in use with OpenLDAP software. When bulk-adding data, you should make sure it is reasonably acceptable. 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 Email: pierangelo.masarati(a)sys-net.it ---------------------------------------

1 0

Re: (ITS#5346) overlay and config backend
by h.b.furuseth＠usit.uio.no 01 Feb '08

01 Feb '08

Well, it's not your overlay's fault. The same happens with overlay unique: It works, but does not show up in ldapsearch. Nor in the config directory written with slapd -f ... -F ... $cat slapd.conf include servers/slapd/schema/core.schema database config rootdn cn=config rootpw secret overlay unique unique_uri ldap:///?olcAccess?sub access to * by * read $ ldapmodify -xHldap://:3890 -D cn=config -w secret dn: olcDatabase={-1}frontend,cn=config changetype: modify add: olcAccess olcAccess: to * by * read - modifying entry "olcDatabase={-1}frontend,cn=config" ldap_modify: Constraint violation (19) additional info: some attributes not unique On the other hand, this is strange: > cn=config > - cn= schema > - cn={0}core > - olcDatabase={-1}frontend > - olcDatabase={0}config > - olcDatabase={-1}ndb_pl > + olcoverlay={0}ndbover Two different databases should not have the same number. ndb_pl should get {1}. Possibly your backend or overlay messes up something in that regard. -- Hallvard

1 0

(ITS#5350) Request: ITS links in mailinglist archives
by h.b.furuseth＠usit.uio.no 01 Feb '08

01 Feb '08

Full_Name: Hallvard B Furuseth Version: OS: URL: Submission from: (NULL) (129.240.6.233) Submitted by: hallvard Could the mailinglist->web archiver put <a href="/its/?findid=(number)"></a> around "ITS#(number)" in the messages? Links for RFCs would be useful too.

1 0

Re: (ITS#5342) DN and naming attribute mismatch
by h.b.furuseth＠usit.uio.no 01 Feb '08

01 Feb '08

Aaron Richton writes: > In the meantime, thanks for the db_dump idea; I can now show that the bad > commits are definitely (a) 2.3.40 and (b) increasing. Can db->set_flags(db, DB_CHKSUM) help narrow it down? It's not a database environment flag, for some reason. http://www.oracle.com/technology/documentation/berkeley-db/db/api_c/db_set_… Not relevant for this ITS, but if it's made a slapd.conf option instead of just a hack for this occasion it would likely be useful to offer a way to say "turn it on if DB page size differs from filesystem block size", since that's one case when Berkeley DB can't guarantee that data remains correct: http://www.oracle.com/technology/documentation/berkeley-db/db/ref/transapp/… -- Hallvard

1 0

Re: (ITS#5348) slapcat on 2.3.38 to slapadd on 2.4.7 causes abort.
by hachi＠kuiki.net 01 Feb '08

01 Feb '08

Tested against both HEAD and OPENLDAP_REL_ENG_2_4, same error: slapadd: schema_init.c:3669: csnNormalize: Assertion `val->bv_len == (sizeof("YYYYmmddHHMMSS.uuuuuuZ#SSSSSS#SID#ssssss")-1)' failed. Aborted

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