openldap-bugs

openldap-bugs@openldap.org

1 participants
20960 discussions

Re: (ITS#7764) RFE: library lber method which returns the ber size even if the ber is overflown
by hyc＠symas.com 15 Dec '13

15 Dec '13

nhosoi(a)gmail.com wrote: > Full_Name: Noriko Hosoi > Version: 2.4.35-4 > OS: Fedora 18 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (209.132.181.86) > > > We use the OpenLdap library in our software. LDAP clients could send too large > ber and cause LBER_OVERFLOW (or LBER_DEFAULT) to the lber APIs. We'd like to > learn how large the ber size we should prepare from the error. When we look > into the BerElement ber using gdb, ber->ber_len stores the value. But the value > is not returned to the caller when the API fails, e.g., by the overflow. Could > it be possible to have a way to retrieve the ber size under any condition? That doesn't sound like OpenLDAP, we have no LBER_OVERFLOW error code. Nor do we have any particular size limits on a BerElement, other than fitting into a long. -- -- 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#7763) undefined references during LTO enabled build
by nheghathivhistha＠gmail.com 14 Dec '13

14 Dec '13

Hello, Thank you. Markus Trippelsdorf told me in my bug report (http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59505) what is the problem cause and how to solve it - it is not existing support for slim-LTO-model in binutils. AS=gcc-as AR=gcc-ar NM=gcc-nm RANLIB=gcc-ranlib did it for me for Openldap package in Gentoo too . Best regards, David. 2013/12/13 Howard Chu <hyc(a)symas.com>: > nheghathivhistha(a)gmail.com wrote: >> >> Full_Name: David Kredba >> Version: 2.4.38 >> OS: Linux >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (88.101.228.82) >> >> >> I am trying to rebuild my system with LTO enabled gcc. >> >> Compilation of Gentoo package /net-nds/openldap-2.4.38-r1 ended with: > > > You cut off the trace just at the crucial line. It should say, e.g.: > > ar ru librewrite.a config.o context.o info.o ldapmap.o map.o params.o rule.o > session.o subst.o var.o xmap.o version.o > ar: creating librewrite.a > > Anyway, I see no build errors here. Closing this ITS. Ask for help on the > -technical mailing list. > >> x86_64-pc-linux-gnu-ar: creating librewrite.a >> /bin/bash ../../libtool --mode=link x86_64-pc-linux-gnu-gcc -O2 -ggdb >> -pipe >> -march=native -mtune=native -flto=4 -fuse-linker-plugin -D_GNU_SOURCE >> -Wl,--as-needed -Wl,-O1 -Wl,--hash-style=gnu -Wl,--sort-common -O2 -ggdb >> -pipe >> -march=native -mtune=native -flto=4 -fuse-linker-plugin -o rewrite >> rewrite.o >> parse.o librewrite.a ../../libraries/liblutil/liblutil.a >> ../../libraries/libldap_r/libldap_r.la ../../libraries/liblber/liblber.la >> -lssl -lcrypto -lcrypt -lresolv -pthread >> libtool: link: x86_64-pc-linux-gnu-gcc -O2 -ggdb -pipe -march=native >> -mtune=native -flto=4 -fuse-linker-plugin -D_GNU_SOURCE -Wl,-O1 >> -Wl,--hash-style=gnu -Wl,--sort-common -O2 -ggdb -pipe -march=native >> -mtune=native -flto=4 -fuse-linker-plugin -o .libs/rewrite rewrite.o >> parse.o >> -pthread -Wl,--as-needed librewrite.a ../../libraries/liblutil/liblutil.a >> ../../libraries/libldap_r/.libs/libldap_r.so >> >> /var/tmp/portage/net-nds/openldap-2.4.38-r1/work/openldap-2.4.38/libraries/liblber/.libs/liblber.so >> ../../libraries/liblber/.libs/liblber.so -lssl -lcrypto -lcrypt -lresolv >> -pthread >> >> /var/tmp/portage/net-nds/openldap-2.4.38-r1/temp/ccTxyjV6.ltrans0.ltrans.o: >> In >> function `rewrite_read': >> >> /var/tmp/portage/net-nds/openldap-2.4.38-r1/work/openldap-2.4.38/libraries/librewrite/parse.c:112: >> undefined reference to `rewrite_parse' >> >> /var/tmp/portage/net-nds/openldap-2.4.38-r1/temp/ccTxyjV6.ltrans0.ltrans.o: >> In >> function `main': >> >> /var/tmp/portage/net-nds/openldap-2.4.38-r1/work/openldap-2.4.38/libraries/librewrite/rewrite.c:141: >> undefined reference to `lutil_atoix' >> >> /var/tmp/portage/net-nds/openldap-2.4.38-r1/temp/ccTxyjV6.ltrans0.ltrans.o: >> In >> function `apply': >> >> /var/tmp/portage/net-nds/openldap-2.4.38-r1/work/openldap-2.4.38/libraries/librewrite/rewrite.c:52: >> undefined reference to `rewrite_info_init' >> >> /var/tmp/portage/net-nds/openldap-2.4.38-r1/work/openldap-2.4.38/libraries/librewrite/rewrite.c:58: >> undefined reference to `rewrite_param_set' >> >> /var/tmp/portage/net-nds/openldap-2.4.38-r1/work/openldap-2.4.38/libraries/librewrite/rewrite.c:60: >> undefined reference to `rewrite_session_init' >> >> /var/tmp/portage/net-nds/openldap-2.4.38-r1/work/openldap-2.4.38/libraries/librewrite/rewrite.c:75: >> undefined reference to `rewrite_session' >> >> /var/tmp/portage/net-nds/openldap-2.4.38-r1/work/openldap-2.4.38/libraries/librewrite/rewrite.c:120: >> undefined reference to `rewrite_session_delete' >> >> /var/tmp/portage/net-nds/openldap-2.4.38-r1/work/openldap-2.4.38/libraries/librewrite/rewrite.c:122: >> undefined reference to `rewrite_info_delete' >> collect2: error: ld returned 1 exit status >> Makefile:290: recipe for target 'rewrite' failed >> make[2]: *** [rewrite] Error 1 >> make[2]: Leaving directory >> >> '/var/tmp/portage/net-nds/openldap-2.4.38-r1/work/openldap-2.4.38/libraries/librewrite' >> Makefile:296: recipe for target 'all-common' failed >> make[1]: *** [all-common] Error 1 >> make[1]: Leaving directory >> >> '/var/tmp/portage/net-nds/openldap-2.4.38-r1/work/openldap-2.4.38/libraries' >> Makefile:312: recipe for target 'all-common' failed >> >> Coul you kindly please look into it? I think that header(s) can be missing >> in >> source files and library(ies) at link time. >> >> I uploaded david-kredba-20131213-build.log and >> david-kredba-20131213-config.log >> to your ftp server. >> >> Thank you in advance. >> >> > > > -- > -- 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#7764) RFE: library lber method which returns the ber size even if the ber is overflown
by nhosoi＠gmail.com 13 Dec '13

13 Dec '13

Full_Name: Noriko Hosoi Version: 2.4.35-4 OS: Fedora 18 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (209.132.181.86) We use the OpenLdap library in our software. LDAP clients could send too large ber and cause LBER_OVERFLOW (or LBER_DEFAULT) to the lber APIs. We'd like to learn how large the ber size we should prepare from the error. When we look into the BerElement ber using gdb, ber->ber_len stores the value. But the value is not returned to the caller when the API fails, e.g., by the overflow. Could it be possible to have a way to retrieve the ber size under any condition?

1 0

Re: (ITS#7763) undefined references during LTO enabled build
by hyc＠symas.com 13 Dec '13

13 Dec '13

nheghathivhistha(a)gmail.com wrote: > Full_Name: David Kredba > Version: 2.4.38 > OS: Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (88.101.228.82) > > > I am trying to rebuild my system with LTO enabled gcc. > > Compilation of Gentoo package /net-nds/openldap-2.4.38-r1 ended with: You cut off the trace just at the crucial line. It should say, e.g.: ar ru librewrite.a config.o context.o info.o ldapmap.o map.o params.o rule.o session.o subst.o var.o xmap.o version.o ar: creating librewrite.a Anyway, I see no build errors here. Closing this ITS. Ask for help on the -technical mailing list. > x86_64-pc-linux-gnu-ar: creating librewrite.a > /bin/bash ../../libtool --mode=link x86_64-pc-linux-gnu-gcc -O2 -ggdb -pipe > -march=native -mtune=native -flto=4 -fuse-linker-plugin -D_GNU_SOURCE > -Wl,--as-needed -Wl,-O1 -Wl,--hash-style=gnu -Wl,--sort-common -O2 -ggdb -pipe > -march=native -mtune=native -flto=4 -fuse-linker-plugin -o rewrite rewrite.o > parse.o librewrite.a ../../libraries/liblutil/liblutil.a > ../../libraries/libldap_r/libldap_r.la ../../libraries/liblber/liblber.la > -lssl -lcrypto -lcrypt -lresolv -pthread > libtool: link: x86_64-pc-linux-gnu-gcc -O2 -ggdb -pipe -march=native > -mtune=native -flto=4 -fuse-linker-plugin -D_GNU_SOURCE -Wl,-O1 > -Wl,--hash-style=gnu -Wl,--sort-common -O2 -ggdb -pipe -march=native > -mtune=native -flto=4 -fuse-linker-plugin -o .libs/rewrite rewrite.o parse.o > -pthread -Wl,--as-needed librewrite.a ../../libraries/liblutil/liblutil.a > ../../libraries/libldap_r/.libs/libldap_r.so > /var/tmp/portage/net-nds/openldap-2.4.38-r1/work/openldap-2.4.38/libraries/liblber/.libs/liblber.so > ../../libraries/liblber/.libs/liblber.so -lssl -lcrypto -lcrypt -lresolv > -pthread > /var/tmp/portage/net-nds/openldap-2.4.38-r1/temp/ccTxyjV6.ltrans0.ltrans.o: In > function `rewrite_read': > /var/tmp/portage/net-nds/openldap-2.4.38-r1/work/openldap-2.4.38/libraries/librewrite/parse.c:112: > undefined reference to `rewrite_parse' > /var/tmp/portage/net-nds/openldap-2.4.38-r1/temp/ccTxyjV6.ltrans0.ltrans.o: In > function `main': > /var/tmp/portage/net-nds/openldap-2.4.38-r1/work/openldap-2.4.38/libraries/librewrite/rewrite.c:141: > undefined reference to `lutil_atoix' > /var/tmp/portage/net-nds/openldap-2.4.38-r1/temp/ccTxyjV6.ltrans0.ltrans.o: In > function `apply': > /var/tmp/portage/net-nds/openldap-2.4.38-r1/work/openldap-2.4.38/libraries/librewrite/rewrite.c:52: > undefined reference to `rewrite_info_init' > /var/tmp/portage/net-nds/openldap-2.4.38-r1/work/openldap-2.4.38/libraries/librewrite/rewrite.c:58: > undefined reference to `rewrite_param_set' > /var/tmp/portage/net-nds/openldap-2.4.38-r1/work/openldap-2.4.38/libraries/librewrite/rewrite.c:60: > undefined reference to `rewrite_session_init' > /var/tmp/portage/net-nds/openldap-2.4.38-r1/work/openldap-2.4.38/libraries/librewrite/rewrite.c:75: > undefined reference to `rewrite_session' > /var/tmp/portage/net-nds/openldap-2.4.38-r1/work/openldap-2.4.38/libraries/librewrite/rewrite.c:120: > undefined reference to `rewrite_session_delete' > /var/tmp/portage/net-nds/openldap-2.4.38-r1/work/openldap-2.4.38/libraries/librewrite/rewrite.c:122: > undefined reference to `rewrite_info_delete' > collect2: error: ld returned 1 exit status > Makefile:290: recipe for target 'rewrite' failed > make[2]: *** [rewrite] Error 1 > make[2]: Leaving directory > '/var/tmp/portage/net-nds/openldap-2.4.38-r1/work/openldap-2.4.38/libraries/librewrite' > Makefile:296: recipe for target 'all-common' failed > make[1]: *** [all-common] Error 1 > make[1]: Leaving directory > '/var/tmp/portage/net-nds/openldap-2.4.38-r1/work/openldap-2.4.38/libraries' > Makefile:312: recipe for target 'all-common' failed > > Coul you kindly please look into it? I think that header(s) can be missing in > source files and library(ies) at link time. > > I uploaded david-kredba-20131213-build.log and david-kredba-20131213-config.log > to your ftp server. > > Thank you in advance. > > -- -- 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#7763) undefined references during LTO enabled build
by nheghathivhistha＠gmail.com 13 Dec '13

13 Dec '13

Full_Name: David Kredba Version: 2.4.38 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (88.101.228.82) I am trying to rebuild my system with LTO enabled gcc. Compilation of Gentoo package /net-nds/openldap-2.4.38-r1 ended with: x86_64-pc-linux-gnu-ar: creating librewrite.a /bin/bash ../../libtool --mode=link x86_64-pc-linux-gnu-gcc -O2 -ggdb -pipe -march=native -mtune=native -flto=4 -fuse-linker-plugin -D_GNU_SOURCE -Wl,--as-needed -Wl,-O1 -Wl,--hash-style=gnu -Wl,--sort-common -O2 -ggdb -pipe -march=native -mtune=native -flto=4 -fuse-linker-plugin -o rewrite rewrite.o parse.o librewrite.a ../../libraries/liblutil/liblutil.a ../../libraries/libldap_r/libldap_r.la ../../libraries/liblber/liblber.la -lssl -lcrypto -lcrypt -lresolv -pthread libtool: link: x86_64-pc-linux-gnu-gcc -O2 -ggdb -pipe -march=native -mtune=native -flto=4 -fuse-linker-plugin -D_GNU_SOURCE -Wl,-O1 -Wl,--hash-style=gnu -Wl,--sort-common -O2 -ggdb -pipe -march=native -mtune=native -flto=4 -fuse-linker-plugin -o .libs/rewrite rewrite.o parse.o -pthread -Wl,--as-needed librewrite.a ../../libraries/liblutil/liblutil.a ../../libraries/libldap_r/.libs/libldap_r.so /var/tmp/portage/net-nds/openldap-2.4.38-r1/work/openldap-2.4.38/libraries/liblber/.libs/liblber.so ../../libraries/liblber/.libs/liblber.so -lssl -lcrypto -lcrypt -lresolv -pthread /var/tmp/portage/net-nds/openldap-2.4.38-r1/temp/ccTxyjV6.ltrans0.ltrans.o: In function `rewrite_read': /var/tmp/portage/net-nds/openldap-2.4.38-r1/work/openldap-2.4.38/libraries/librewrite/parse.c:112: undefined reference to `rewrite_parse' /var/tmp/portage/net-nds/openldap-2.4.38-r1/temp/ccTxyjV6.ltrans0.ltrans.o: In function `main': /var/tmp/portage/net-nds/openldap-2.4.38-r1/work/openldap-2.4.38/libraries/librewrite/rewrite.c:141: undefined reference to `lutil_atoix' /var/tmp/portage/net-nds/openldap-2.4.38-r1/temp/ccTxyjV6.ltrans0.ltrans.o: In function `apply': /var/tmp/portage/net-nds/openldap-2.4.38-r1/work/openldap-2.4.38/libraries/librewrite/rewrite.c:52: undefined reference to `rewrite_info_init' /var/tmp/portage/net-nds/openldap-2.4.38-r1/work/openldap-2.4.38/libraries/librewrite/rewrite.c:58: undefined reference to `rewrite_param_set' /var/tmp/portage/net-nds/openldap-2.4.38-r1/work/openldap-2.4.38/libraries/librewrite/rewrite.c:60: undefined reference to `rewrite_session_init' /var/tmp/portage/net-nds/openldap-2.4.38-r1/work/openldap-2.4.38/libraries/librewrite/rewrite.c:75: undefined reference to `rewrite_session' /var/tmp/portage/net-nds/openldap-2.4.38-r1/work/openldap-2.4.38/libraries/librewrite/rewrite.c:120: undefined reference to `rewrite_session_delete' /var/tmp/portage/net-nds/openldap-2.4.38-r1/work/openldap-2.4.38/libraries/librewrite/rewrite.c:122: undefined reference to `rewrite_info_delete' collect2: error: ld returned 1 exit status Makefile:290: recipe for target 'rewrite' failed make[2]: *** [rewrite] Error 1 make[2]: Leaving directory '/var/tmp/portage/net-nds/openldap-2.4.38-r1/work/openldap-2.4.38/libraries/librewrite' Makefile:296: recipe for target 'all-common' failed make[1]: *** [all-common] Error 1 make[1]: Leaving directory '/var/tmp/portage/net-nds/openldap-2.4.38-r1/work/openldap-2.4.38/libraries' Makefile:312: recipe for target 'all-common' failed Coul you kindly please look into it? I think that header(s) can be missing in source files and library(ies) at link time. I uploaded david-kredba-20131213-build.log and david-kredba-20131213-config.log to your ftp server. Thank you in advance.

1 0

Re: (ITS#7762) ldap_dn2bv_x misbehaves for "empty" dn
by hyc＠symas.com 11 Dec '13

11 Dec '13

marc.schmitzer(a)richard-wolf.com wrote: > Full_Name: Marc Schmitzer > Version: 2.4.28 > OS: Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (217.6.229.211) > > > The ldap_dn2bv_x function misbehaves for the LDAPV2 and LDAPV3 formats when it > is passed an "empty" DN in the form of an LDAPRDN-array whose first element is > NULL. The "len" variable remains zero throughout the function, as no RDNS are > processed. Finally, the bv_len member of the output struct berval is set to > len-1. The result is a berval with bv_len = UINT_MAX. > > Tested with 2.4.28, but the problem appears to present in the current git master > as well. Thanks for the report, fixed now in git master. > > The following code snippet demonstrates the problem: > > #include <stdio.h> > #include <ldap.h> > > int main(int argc, char** argv) > { > LDAPRDN dn[1] = { NULL }; > struct berval bv = { 0, NULL }; > int res = ldap_dn2bv(dn, &bv, LDAP_DN_FORMAT_LDAPV3); > > printf("res: %d\n", res); > printf("len: %u\n", (unsigned int) bv.bv_len); > > return 0; > } > > > Output: > res: 0 > len: 4294967295 > > -- -- 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#7762) ldap_dn2bv_x misbehaves for "empty" dn
by marc.schmitzer＠richard-wolf.com 11 Dec '13

11 Dec '13

Full_Name: Marc Schmitzer Version: 2.4.28 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (217.6.229.211) The ldap_dn2bv_x function misbehaves for the LDAPV2 and LDAPV3 formats when it is passed an "empty" DN in the form of an LDAPRDN-array whose first element is NULL. The "len" variable remains zero throughout the function, as no RDNS are processed. Finally, the bv_len member of the output struct berval is set to len-1. The result is a berval with bv_len = UINT_MAX. Tested with 2.4.28, but the problem appears to present in the current git master as well. The following code snippet demonstrates the problem: #include <stdio.h> #include <ldap.h> int main(int argc, char** argv) { LDAPRDN dn[1] = { NULL }; struct berval bv = { 0, NULL }; int res = ldap_dn2bv(dn, &bv, LDAP_DN_FORMAT_LDAPV3); printf("res: %d\n", res); printf("len: %u\n", (unsigned int) bv.bv_len); return 0; } Output: res: 0 len: 4294967295

1 0

(ITS#7761) Issue with modifying loglevel during long search operation
by mwarren＠symas.com 11 Dec '13

11 Dec '13

Full_Name: Mark Warren Version: 2.4.38 OS: RHEL 5 x86-64 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (199.190.53.83) There is an issue where OpenLDAP will stop sending search results and fail to update a dynamic config when the loglevel is modified during a long search operation. Symptoms: * No further search results sent to client although internally the operation continues. * Log level change does not take effect Cause(Via Howard): * send_search_entry() correctly returns an error because back-config wants a pause * back-bdb/back-hdb ignores this error * The entry it tried to send doesn't get sent, and it just loops back to fetch the next entry instead of quitting Steps to reproduce: 1. Create large sample database. 2 million entries was more than sufficient locally. 2. Issue a search request for all entries. 3. Submit a modify request on olcLogLevel within cn=config while the above search is still in progress. Notes(Also via Howard): * This is not a total hang as everything should resume after the internal search operation finishes. Regards, Mark Warren

1 0

Re: (ITS#7759) Wrong parsing of LDAP message
by hyc＠symas.com 09 Dec '13

09 Dec '13

This is a multi-part message in MIME format. --------------050905040301060400050300 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Lukas Slebodnik wrote: > On (09/12/13 04:01), Howard Chu wrote: >>>> Meanwhile you can refer to draft-behera-ldap-password-policy for the >>>> specification of the response control. The control value is mandatory >>>> for this control. >>> If I read draft "6.2. Response Control" correctly, >>> http://tools.ietf.org/html/draft-behera-ldap-password-policy-10#section-6.2 >>> response can be sequence of "PasswordPolicyResponseValue". >>> I think that sequence means "0 or more values" >> >> The sequence is required to begin with a Sequence marker. >> >>> In theory, there needn't be any password policy response value after control >>> type. In this case, either my patch or your patch are wrong. >>> Did I miss something? >>> >>> The controlType is 1.3.6.1.4.1.42.2.27.8.5.1 and the controlValue is >>> the BER encoding of the following type: >> >> "the controlValue is the BER encoding of a Sequence." - even if the >> sequence has zero members, it cannot be omitted. >> > Thank you for your explanation. > > I am attaching output from ldapwhoami with enabled ppolicy, > but I am sure that problem is in the server apacheds, because there is nothing > after controlType 1.3.6.1.4.1.42.2.27.8.5.1 > (at least Sequence marker should be after controlType) Agreed, that looks like an ApacheDS bug. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/ --------------050905040301060400050300 Content-Type: text/plain; charset=UTF-8; name="ldapwhoami.log" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="ldapwhoami.log" W3Jvb3RAdm0tMjE5IH5dIyBsZGFwd2hvYW1pIC1kNyAtRCAiY249V2lsbGlhbSBCdXNoLG91 PXBlb3BsZSxkYz1leGFtcGxlLGRjPXNrIiAtdyBqYWhvZGEuMTIzIC1IIGxkYXA6Ly92bS0x MzcuaWRtLmxhYi5sb2NhbCAtZSBwcG9saWN5CmxkYXBfdXJsX3BhcnNlX2V4dChsZGFwOi8v dm0tMTM3LmlkbS5sYWIubG9jYWwpCmxkYXBfY3JlYXRlCmxkYXBfdXJsX3BhcnNlX2V4dChs ZGFwOi8vdm0tMTM3LmlkbS5sYWIubG9jYWw6Mzg5Lz8/YmFzZSkKbGRhcF9zYXNsX2JpbmQK bGRhcF9zZW5kX2luaXRpYWxfcmVxdWVzdApsZGFwX25ld19jb25uZWN0aW9uIDEgMSAwCmxk YXBfaW50X29wZW5fY29ubmVjdGlvbgpsZGFwX2Nvbm5lY3RfdG9faG9zdDogVENQIHZtLTEz Ny5pZG0ubGFiLmxvY2FsOjM4OQpsZGFwX25ld19zb2NrZXQ6IDMKbGRhcF9wcmVwYXJlX3Nv Y2tldDogMwpsZGFwX2Nvbm5lY3RfdG9faG9zdDogVHJ5aW5nIDEwLjM0LjQ3LjEzNzozODkK bGRhcF9wdnRfY29ubmVjdDogZmQ6IDMgdG06IC0xIGFzeW5jOiAwCmF0dGVtcHRpbmcgdG8g Y29ubmVjdDogCmNvbm5lY3Qgc3VjY2VzcwpsZGFwX29wZW5fZGVmY29ubjogc3VjY2Vzc2Z1 bApsZGFwX3NlbmRfc2VydmVyX3JlcXVlc3QKYmVyX3NjYW5mIGZtdCAoe2l0KSBiZXI6CmJl cl9zY2FuZiBmbXQgKHtpKSBiZXI6CmJlcl9mbHVzaDI6IDk3IGJ5dGVzIHRvIHNkIDMKbGRh cF93cml0ZTogd2FudD05Nywgd3JpdHRlbj05NwogIDAwMDA6ICAzMCA1ZiAwMiAwMSAwMSA2 MCAzYiAwMiAgMDEgMDMgMDQgMmEgNjMgNmUgM2QgNTcgICAwXy4uLmA7Li4uLipjbj1XICAK ICAwMDEwOiAgNjkgNmMgNmMgNjkgNjEgNmQgMjAgNDIgIDc1IDczIDY4IDJjIDZmIDc1IDNk IDcwICAgaWxsaWFtIEJ1c2gsb3U9cCAgCiAgMDAyMDogIDY1IDZmIDcwIDZjIDY1IDJjIDY0 IDYzICAzZCA2NSA3OCA2MSA2ZCA3MCA2YyA2NSAgIGVvcGxlLGRjPWV4YW1wbGUgIAogIDAw MzA6ICAyYyA2NCA2MyAzZCA3MyA2YiA4MCAwYSAgNmEgNjEgNjggNmYgNjQgNjEgMmUgMzEg ICAsZGM9c2suLmphaG9kYS4xICAKICAwMDQwOiAgMzIgMzMgYTAgMWQgMzAgMWIgMDQgMTkg IDMxIDJlIDMzIDJlIDM2IDJlIDMxIDJlICAgMjMuLjAuLi4xLjMuNi4xLiAgCiAgMDA1MDog IDM0IDJlIDMxIDJlIDM0IDMyIDJlIDMyICAyZSAzMiAzNyAyZSAzOCAyZSAzNSAyZSAgIDQu MS40Mi4yLjI3LjguNS4gIAogIDAwNjA6ICAzMSAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAxICAgICAgICAgICAgICAgICAKbGRhcF9yZXN1bHQg bGQgMHg3ZmMwZTg1N2JkNTAgbXNnaWQgMQp3YWl0NG1zZyBsZCAweDdmYzBlODU3YmQ1MCBt c2dpZCAxIChpbmZpbml0ZSB0aW1lb3V0KQp3YWl0NG1zZyBjb250aW51ZSBsZCAweDdmYzBl ODU3YmQ1MCBtc2dpZCAxIGFsbCAxCioqIGxkIDB4N2ZjMGU4NTdiZDUwIENvbm5lY3Rpb25z OgoqIGhvc3Q6IHZtLTEzNy5pZG0ubGFiLmxvY2FsICBwb3J0OiAzODkgIChkZWZhdWx0KQog IHJlZmNudDogMiAgc3RhdHVzOiBDb25uZWN0ZWQKICBsYXN0IHVzZWQ6IE1vbiBEZWMgIDkg MTM6MTU6MTQgMjAxMwoKCioqIGxkIDB4N2ZjMGU4NTdiZDUwIE91dHN0YW5kaW5nIFJlcXVl c3RzOgogKiBtc2dpZCAxLCAgb3JpZ2lkIDEsIHN0YXR1cyBJblByb2dyZXNzCiAgIG91dHN0 YW5kaW5nIHJlZmVycmFscyAwLCBwYXJlbnQgY291bnQgMAogIGxkIDB4N2ZjMGU4NTdiZDUw IHJlcXVlc3QgY291bnQgMSAoYWJhbmRvbmVkIDApCioqIGxkIDB4N2ZjMGU4NTdiZDUwIFJl c3BvbnNlIFF1ZXVlOgogICBFbXB0eQogIGxkIDB4N2ZjMGU4NTdiZDUwIHJlc3BvbnNlIGNv dW50IDAKbGRhcF9jaGtSZXNwb25zZUxpc3QgbGQgMHg3ZmMwZTg1N2JkNTAgbXNnaWQgMSBh bGwgMQpsZGFwX2Noa1Jlc3BvbnNlTGlzdCByZXR1cm5zIGxkIDB4N2ZjMGU4NTdiZDUwIE5V TEwKbGRhcF9pbnRfc2VsZWN0CnJlYWQxbXNnOiBsZCAweDdmYzBlODU3YmQ1MCBtc2dpZCAx IGFsbCAxCmJlcl9nZXRfbmV4dApsZGFwX3JlYWQ6IHdhbnQ9OCwgZ290PTgKICAwMDAwOiAg MzAgMmIgMDIgMDEgMDEgNjEgMDcgMGEgICAgICAgICAgICAgICAgICAgICAgICAgICAgMCsu Li5hLi4gICAgICAgICAgCmxkYXBfcmVhZDogd2FudD0zNywgZ290PTM3CiAgMDAwMDogIDAx IDAwIDA0IDAwIDA0IDAwIGEwIDFkICAzMCAxYiAwNCAxOSAzMSAyZSAzMyAyZSAgIC4uLi4u Li4uMC4uLjEuMy4gIAogIDAwMTA6ICAzNiAyZSAzMSAyZSAzNCAyZSAzMSAyZSAgMzQgMzIg MmUgMzIgMmUgMzIgMzcgMmUgICA2LjEuNC4xLjQyLjIuMjcuICAKICAwMDIwOiAgMzggMmUg MzUgMmUgMzEgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgOC41LjEgICAg ICAgICAgICAgCmJlcl9nZXRfbmV4dDogdGFnIDB4MzAgbGVuIDQzIGNvbnRlbnRzOgpyZWFk MW1zZzogbGQgMHg3ZmMwZTg1N2JkNTAgbXNnaWQgMSBtZXNzYWdlIHR5cGUgYmluZApiZXJf c2NhbmYgZm10ICh7ZUFBKSBiZXI6CnJlYWQxbXNnOiBsZCAweDdmYzBlODU3YmQ1MCAwIG5l dyByZWZlcnJhbHMKcmVhZDFtc2c6ICBtYXJrIHJlcXVlc3QgY29tcGxldGVkLCBsZCAweDdm YzBlODU3YmQ1MCBtc2dpZCAxCnJlcXVlc3QgZG9uZTogbGQgMHg3ZmMwZTg1N2JkNTAgbXNn aWQgMQpyZXNfZXJybm86IDAsIHJlc19lcnJvcjogPD4sIHJlc19tYXRjaGVkOiA8PgpsZGFw X2ZyZWVfcmVxdWVzdCAob3JpZ2lkIDEsIG1zZ2lkIDEpCmxkYXBfcGFyc2VfcmVzdWx0CmJl cl9zY2FuZiBmbXQgKHtpQUEpIGJlcjoKYmVyX3NjYW5mIGZtdCAoe2EpIGJlcjoKYmVyX3Nj YW5mIGZtdCAofSkgYmVyOgpsZGFwX21zZ2ZyZWUKbGRhcHdob2FtaTogaW8uYzoxMDg6IGJl cl93cml0ZTogQXNzZXJ0aW9uIGBidWYgIT0gKCh2b2lkICopMCknIGZhaWxlZC4KQWJvcnRl ZCAoY29yZSBkdW1wZWQpCltyb290QHZtLTIxOSB+XSMK --------------050905040301060400050300--

1 0

Re: (ITS#7754) Unaligned MDB_DUPSORT sub-pages
by hyc＠symas.com 09 Dec '13

09 Dec '13

h.b.furuseth(a)usit.uio.no wrote: > 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. Sounds fine to me. back-mdb only uses even-sized keys with DUPSORT, so this change has no impact on OpenLDAP. And most likely no one else has hit this situation yet otherwise they'd be crashing. > 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: > -- -- 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

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