openldap-bugs

openldap-bugs@openldap.org

1 participants
21065 discussions

Re: (ITS#7754) Unaligned MDB_DUPSORT sub-pages
by h.b.furuseth＠usit.uio.no 26 Nov '13

26 Nov '13

I wrote: > (...) > A fix with a format change would be to put the padding byte in front > of the sub-page instead of at the end. Ignore next paragraph: > One fix with a format change could be that the data item gets uneven > size too, with a padding byte in front of the sub-page. Because that's repeated as the 2nd alternative after this one: > The most general way would be to do that in all nodes with uneven- > sized key and even-sized data: -- Hallvard

1 0

(ITS#7754) Unaligned MDB_DUPSORT sub-pages
by h.b.furuseth＠usit.uio.no 26 Nov '13

26 Nov '13

Full_Name: Hallvard B Furuseth Version: LMDB_0.9.10 OS: Linux x86_64 URL: Submission from: (NULL) (81.191.45.35) Submitted by: hallvard Uneven-sized keys in MDB_DUPSORT databases get unaligned sub-pages, and thus everything inside their sub-pages gets unaligned too. A fix preserving the current format when !MISALIGNED_OK would be more memcpying, e.g. in COPY_PGNO(). dcmp functions would do byte by byte comparison for such sub-pages. MDB_page.mp_flags could be split two uint8_t fields: mp_flags, mp_zero (zero for now anyway). Renumber P_KEEP to 0x80 or P_META. A fix with a format change would be to put the padding byte in front of the sub-page instead of at the end. One fix with a format change could be that the data item gets uneven size too, with a padding byte in front of the sub-page. The most general way would be to do that in all nodes with uneven- sized key and even-sized data: #define NODEDATA(node) ((void *) ((char *)(node)->mn_data + \ (node)->mn_ksize + ((node)->mn_ksize & ~(node)->mn_lo & 1))) Or do it only with sub-pages. Make the data item uneven-sized so code which is not interested in whether this is a sub-page, need not know about the hack. Access the sub-page specially: #define NODEPAGE(node) ((MDB_page *) \ ((char *)(node)->mn_data + (((node)->mn_ksize + 1) & -2))) That could be coded so the old format is still readable. Then a utility can walk all databases and adjust sub-pages so they have padding in front instead of at the end, so no dump/reload will be needed: /** Address of the possibly 2-byte aligned sub-page in a node. * If the data item has uneven size, then the first byte is * padding to re-align the sub-page after an uneven-sized key. */ #define NODEPAGE(node) ((MDB_page *) \ ((char *)(node)->mn_data + (node)->mn_ksize + ((node)->mn_lo & 1)))

1 0

(ITS#7753) "make" should not be hardcoded
by dam＠opencsw.org 26 Nov '13

26 Nov '13

Full_Name: Dagobert Michelsen Version: 2.4.38 OS: Solaris URL: http://sourceforge.net/apps/trac/gar/browser/csw/mgar/pkg/openldap/trunk/fi… Submission from: (NULL) (86.103.212.188) In Makefile.in the tests are invoked with "make test" which breaks if make has a different name (e.g. gmake) and should better be invoked with "$(MAKE) test". This tiny patch also fixes the issue: http://sourceforge.net/apps/trac/gar/browser/csw/mgar/pkg/openldap/trunk/fi…

1 0

Re: (ITS#7589) MDB nodesize issues
by h.b.furuseth＠usit.uio.no 25 Nov '13

25 Nov '13

Howard Chu writes: > Explicitly documented: > > /** Header for a single key/data pair within a page. > * We guarantee 2-byte alignment for nodes. > */ > typedef struct MDB_node { ...er, that's false for LEAF2 nodes since we don't reject uneven-sized DUPFIXED keys. But that part seems to work fine, it's the non-LEAF2 which breaks. -- Hallvard

1 0

Re: (ITS#7589) MDB nodesize issues
by h.b.furuseth＠usit.uio.no 25 Nov '13

25 Nov '13

Howard Chu writes: > Hallvard Breien Furuseth wrote: > "Non-LEAF2 nodes are >> even-sized" feels like a deeply embedded assumption, but I haven't >> really looked. > > Explicitly documented: > > /** Header for a single key/data pair within a page. > * We guarantee 2-byte alignment for nodes. > */ > typedef struct MDB_node { > > Obviously you cannot guarantee 2-byte alignment unless nodes are always even > sized. Indeed. But I was wondering how hard to try to rescue databases where that doc is false. -- Hallvard

1 0

Re: (ITS#7589) MDB nodesize issues
by hyc＠symas.com 25 Nov '13

25 Nov '13

Hallvard Breien Furuseth wrote: "Non-LEAF2 nodes are > even-sized" feels like a deeply embedded assumption, but I haven't > really looked. Explicitly documented: /** Header for a single key/data pair within a page. * We guarantee 2-byte alignment for nodes. */ typedef struct MDB_node { Obviously you cannot guarantee 2-byte alignment unless nodes are always even sized. -- -- 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#7589) MDB nodesize issues
by h.b.furuseth＠usit.uio.no 25 Nov '13

25 Nov '13

Howard Chu writes: > Fixed now in mdb.master. (...) The me_nodemax issue remains though. Should be fixed in my branch "mdb/its7589". However, another issue: mdb_node_shrink() can give the node containing the sub-page uneven size, if MDB_DUPFIXED keys have uneven size: mdb_dbi_open(txn, "db", MDB_DUPSORT|MDB_DUPFIXED, &dbi); mdb_put(txn, dbi, &(MDB_val){4, "key"}, &(MDB_val){1, "A"}, 0); mdb_put(txn, dbi, &(MDB_val){4, "key"}, &(MDB_val){1, "B"}, 0); mdb_del(txn, dbi, &(MDB_val){4, "key"}, &(MDB_val){1, "B"}); Fix: Do nothing if the node would be uneven-sized. Similar to how mdb_cursor_put() adds room for 4N nodes at a time, with MDB_DUPFIXED. Dunno if the cursor tracking code in mdb_cursor_del() must still run. I don't know what to do about databases that already contain such uneven-sized nodes. Maybe support reading them (if that needs any changes), but try to assert when writing. "Non-LEAF2 nodes are even-sized" feels like a deeply embedded assumption, but I haven't really looked. -- Hallvard

1 0

Re: (ITS#7750) bdb/hdb modify olcDbConfig is broken
by hyc＠symas.com 18 Nov '13

18 Nov '13

hyc(a)OpenLDAP.org wrote: > Full_Name: Howard Chu > Version: 2.4.38 > OS: > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (78.192.187.24) > Submitted by: hyc > > > Modifying olcDbConfig deletes the old DB_CONFIG file but doesn't write any new > values out because the new values got freed before we reopen the backend. A fix > is coming shortly. This appears to be a regression due to ITS#7338 which was released in 2.4.32. -- -- 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

(ITS#7750) bdb/hdb modify olcDbConfig is broken
by hyc＠OpenLDAP.org 18 Nov '13

18 Nov '13

Full_Name: Howard Chu Version: 2.4.38 OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (78.192.187.24) Submitted by: hyc Modifying olcDbConfig deletes the old DB_CONFIG file but doesn't write any new values out because the new values got freed before we reopen the backend. A fix is coming shortly.

1 0

Re: (ITS#7739) Include of include badly handled while converting from slapd.conf to slapd.d
by jsynacek＠redhat.com 18 Nov '13

18 Nov '13

On 11/05/2013 04:36 PM, hyc(a)symas.com wrote: > Raphaël Ouazana-Sustowski wrote: >> Hi, >> >> Le 04/11/2013 17:06, Howard Chu a écrit : >>> raphael.ouazana(a)linagora.com wrote: >>>> Full_Name: Raphael Ouazana >>>> Version: 2.4.37 >>>> OS: Linux >>>> URL: ftp://ftp.openldap.org/incoming/ >>>> Submission from: (NULL) (88.173.78.196) >>>> >>>> >>>> Hi, >>>> >>>> If I have for example a main slapd.conf with: >>>> include <path>schema.conf >>>> >>>> And a simple schema.conf: >>>> include <path>core.schema >>>> include <path>cosine.schema >>>> include <path>inetorgperson.schema >>>> >>>> When I try to convert slapd.conf to slapd.d with slaptest, the >>>> resulting >>>> configuration is incorrect: the schema file are not included. >>>> >>> >>> Try again, using a different name than "schema.conf" >> >> It doesn't work neither. >> >> Steps to reproduce: >> >> 1. basic slapd.conf, but: >> a. replace include <schemapath>core.schema by include >> <configpath>morethings.conf >> b. add index sn eq at the end >> >> 2. create <configpath>morethings.conf including only >> <schemapath>core.schema > > Fixed now in master. > Thanks, http://www.openldap.org/its/index.cgi?findid=7626. -- Jan Synacek Software Engineer, Red Hat

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