- openldap-bugs - openldap.org

Re: (ITS#8830) build hardcodes gcc
by hyc＠symas.com 02 Apr '18

02 Apr '18

vcunat(a)gmail.com wrote: > On 04/01/2018 12:37 PM, Howard Chu wrote: >> vcunat(a)gmail.com wrote: >>> On 04/01/2018 12:12 PM, Howard Chu wrote: >>>> The rules you patched are only for generating gcov-compatible binari= es. >>>> They aren't even invoked by "make test" so I don't see why this has = any >>>> impact on your build at all. >>>> >>> >>> The build looks like this: >>> ... >>> running tests >>> ar rs liblmdb.a mdb.o midl.o >>> gcc -pthread -O2 -g -W -Wall -Wno-unused-parameter -Wbad-function-cas= t >>> -Wuninitialized=C3=82 =C3=82 mdb_stat.o liblmdb.a=C3=82 -o mdb_stat >>> make: gcc: Command not found >> >> What's the actual command line you used to invoke this? >=20 > It should be basically `make` before that part and `make test` in the > "running tests" part. Some build flags were passed, too. >=20 > Hmm, weird, I can't see why make decided to do this, and it doesn't > happen with Linux+clang locally (I have no direct access to osx now). > Maybe I'm just tired ATM. Possibly the full failed build log will shed > light on this? > https://logs.nix.ci/?key=3Dnixos/nixpkgs.38289&attempt_id=3De3767f8e-8c= 1e-4404-93b1-d23d9fe429ee >=20 > If you can't see why, I'll try to revisit this weirdness to avoid > potential surprises in future. The log doesn't show the actual command invocations. Most likely your "ma= ke=20 test" isn't setting CC=3Dgcc. It's probably also doing something else wei= rd=20 since it's building liblmdb.a twice. Regardless, there is no bug in the L= MDB=20 Makefile, your build invocations are broken. Closing this ITS. --=20 -- 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#8830) build hardcodes gcc
by vcunat＠gmail.com 01 Apr '18

01 Apr '18

On 04/01/2018 12:37 PM, Howard Chu wrote: > vcunat(a)gmail.com wrote: >> On 04/01/2018 12:12 PM, Howard Chu wrote: >>> The rules you patched are only for generating gcov-compatible binaries. >>> They aren't even invoked by "make test" so I don't see why this has any >>> impact on your build at all. >>> >> >> The build looks like this: >> ... >> running tests >> ar rs liblmdb.a mdb.o midl.o >> gcc -pthread -O2 -g -W -Wall -Wno-unused-parameter -Wbad-function-cast >> -Wuninitialized mdb_stat.o liblmdb.a -o mdb_stat >> make: gcc: Command not found > > What's the actual command line you used to invoke this? It should be basically `make` before that part and `make test` in the "running tests" part. Some build flags were passed, too. Hmm, weird, I can't see why make decided to do this, and it doesn't happen with Linux+clang locally (I have no direct access to osx now). Maybe I'm just tired ATM. Possibly the full failed build log will shed light on this? https://logs.nix.ci/?key=nixos/nixpkgs.38289&attempt_id=e3767f8e-8c1e-4404-… If you can't see why, I'll try to revisit this weirdness to avoid potential surprises in future.

1 0

Re: (ITS#8830) build hardcodes gcc
by hyc＠symas.com 01 Apr '18

01 Apr '18

vcunat(a)gmail.com wrote: > On 04/01/2018 12:12 PM, Howard Chu wrote: >> The rules you patched are only for generating gcov-compatible binaries. >> They aren't even invoked by "make test" so I don't see why this has any >> impact on your build at all. >> > > The build looks like this: > ... > running tests > ar rs liblmdb.a mdb.o midl.o > gcc -pthread -O2 -g -W -Wall -Wno-unused-parameter -Wbad-function-cast > -Wuninitialized mdb_stat.o liblmdb.a -o mdb_stat > make: gcc: Command not found What's the actual command line you used to invoke this? -- -- 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#8830) build hardcodes gcc
by vcunat＠gmail.com 01 Apr '18

01 Apr '18

On 04/01/2018 12:12 PM, Howard Chu wrote: > The rules you patched are only for generating gcov-compatible binaries. > They aren't even invoked by "make test" so I don't see why this has any > impact on your build at all. > The build looks like this: ... running tests ar rs liblmdb.a mdb.o midl.o gcc -pthread -O2 -g -W -Wall -Wno-unused-parameter -Wbad-function-cast -Wuninitialized mdb_stat.o liblmdb.a -o mdb_stat make: gcc: Command not found

1 0

Re: (ITS#8830) build hardcodes gcc
by hyc＠symas.com 01 Apr '18

01 Apr '18

vcunat(a)gmail.com wrote: > On 04/01/2018 11:53 AM, Howard Chu wrote: >> The coverage flags have only been tested with gcc. What compiler are you >> using that also provides code coverage with these flags? > > This is clang on osx, kind of. > > NixOS.org is packaging lmdb for various "platforms", including osx. And > we run `make test` to be more confident about the result. That's what > now broke when we attempt lmdb: 0.9.21 -> 0.9.22 - and this patch fixed > the build (though I didn't really check anything; I don't really have > any osx machine myself). > > My experience in general is that clang tries to be compatible with gcc. The rules you patched are only for generating gcov-compatible binaries. They aren't even invoked by "make test" so I don't see why this has any impact on your build at all. -- -- 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#8830) build hardcodes gcc
by vcunat＠gmail.com 01 Apr '18

01 Apr '18

On 04/01/2018 11:53 AM, Howard Chu wrote: > The coverage flags have only been tested with gcc. What compiler are you > using that also provides code coverage with these flags? This is clang on osx, kind of. NixOS.org is packaging lmdb for various "platforms", including osx. And we run `make test` to be more confident about the result. That's what now broke when we attempt lmdb: 0.9.21 -> 0.9.22 - and this patch fixed the build (though I didn't really check anything; I don't really have any osx machine myself). My experience in general is that clang tries to be compatible with gcc.

1 0

Re: (ITS#8830) build hardcodes gcc
by hyc＠symas.com 01 Apr '18

01 Apr '18

vcunat(a)gmail.com wrote: > Full_Name: Vladim.r &#268;un.t > Version: 0.9.22 (lmdb) > OS: Linux (NixOS) > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (178.255.168.34) >=20 >=20 > Some parts of the LMDB Makefile hardcode gcc, seemingly unnecessarily. = Please > apply the following patch or some similar fix. The coverage flags have only been tested with gcc. What compiler are you = using=20 that also provides code coverage with these flags? >=20 > commit 029031a68873bc3784a8561bd8e049efbd34f9d0 (HEAD) > Author: Vladim=C3=ADr Čun=C3=A1t <vcunat(a)gmail.com> > Date: Sun Apr 1 11:05:31 2018 +0200 >=20 > make: gcc -> $(CC) >=20 > diff --git a/libraries/liblmdb/Makefile b/libraries/liblmdb/Makefile > index f254511..612484e 100644 > --- a/libraries/liblmdb/Makefile > +++ b/libraries/liblmdb/Makefile > @@ -102,13 +102,13 @@ COV_OBJS=3Dxmdb.o xmidl.o > =20 > coverage: xmtest > for i in mtest*.c [0-9]*.c; do j=3D`basename \$$i .c`; $(MAKE) $$j.o= ; \ > - gcc -o x$$j $$j.o $(COV_OBJS) -pthread $(COV_FLAGS); \ > + $(CC) -o x$$j $$j.o $(COV_OBJS) -pthread $(COV_FLAGS); \ > rm -rf testdb; mkdir testdb; ./x$$j; done > gcov xmdb.c > gcov xmidl.c > =20 > xmtest: mtest.o xmdb.o xmidl.o > - gcc -o xmtest mtest.o xmdb.o xmidl.o -pthread $(COV_FLAGS) > + $(CC) -o xmtest mtest.o xmdb.o xmidl.o -pthread $(COV_FLAGS) > =20 > xmdb.o: mdb.c lmdb.h midl.h > $(CC) $(CFLAGS) -fPIC $(CPPFLAGS) -O0 $(COV_FLAGS) -c mdb.c -o $@ >=20 >=20 --=20 -- 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#8829) Right shift build warning VS2017 mdb.c
by hyc＠symas.com 01 Apr '18

01 Apr '18

robin.rowe(a)cinepaint.org wrote: > Full_Name: Robin Rowe > Version: git > OS: Windows 10 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (23.242.20.216) > > > Warning from VS2017: > > mdb.c(7455): warning C4333: '>>': right shift by too large amount, data loss > > 7455: SETDSZ(node, nsize); > > 960: #define SETDSZ(node,size) do { \ > 961: (node)->mn_lo = (size) & 0xffff; (node)->mn_hi = (size) >> 16;} while(0) > > Intentional and irrelevant. Closing this ITS. -- -- 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#8830) build hardcodes gcc
by vcunat＠gmail.com 01 Apr '18

01 Apr '18

Full_Name: Vladim.r &#268;un.t Version: 0.9.22 (lmdb) OS: Linux (NixOS) URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (178.255.168.34) Some parts of the LMDB Makefile hardcode gcc, seemingly unnecessarily. Please apply the following patch or some similar fix. commit 029031a68873bc3784a8561bd8e049efbd34f9d0 (HEAD) Author: Vladimír Čunát <vcunat(a)gmail.com> Date: Sun Apr 1 11:05:31 2018 +0200 make: gcc -> $(CC) diff --git a/libraries/liblmdb/Makefile b/libraries/liblmdb/Makefile index f254511..612484e 100644 --- a/libraries/liblmdb/Makefile +++ b/libraries/liblmdb/Makefile @@ -102,13 +102,13 @@ COV_OBJS=xmdb.o xmidl.o coverage: xmtest for i in mtest*.c [0-9]*.c; do j=`basename \$$i .c`; $(MAKE) $$j.o; \ - gcc -o x$$j $$j.o $(COV_OBJS) -pthread $(COV_FLAGS); \ + $(CC) -o x$$j $$j.o $(COV_OBJS) -pthread $(COV_FLAGS); \ rm -rf testdb; mkdir testdb; ./x$$j; done gcov xmdb.c gcov xmidl.c xmtest: mtest.o xmdb.o xmidl.o - gcc -o xmtest mtest.o xmdb.o xmidl.o -pthread $(COV_FLAGS) + $(CC) -o xmtest mtest.o xmdb.o xmidl.o -pthread $(COV_FLAGS) xmdb.o: mdb.c lmdb.h midl.h $(CC) $(CFLAGS) -fPIC $(CPPFLAGS) -O0 $(COV_FLAGS) -c mdb.c -o $@

1 0

(ITS#8829) Right shift build warning VS2017 mdb.c
by robin.rowe＠cinepaint.org 01 Apr '18

01 Apr '18

Full_Name: Robin Rowe Version: git OS: Windows 10 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (23.242.20.216) Warning from VS2017: mdb.c(7455): warning C4333: '>>': right shift by too large amount, data loss 7455: SETDSZ(node, nsize); 960: #define SETDSZ(node,size) do { \ 961: (node)->mn_lo = (size) & 0xffff; (node)->mn_hi = (size) >> 16;} while(0)

1 0

Re: (ITS#8827) lmdb from master fails to build with Visual Studio 2015.
by quanah＠symas.com 29 Mar '18

29 Mar '18

--On Thursday, March 29, 2018 9:20 PM +0000 rion4ik(a)gmail.com wrote: > Why do you use this mail-based crap? We won't be for much longer: <http://www.openldap.org/lists/openldap-devel/201801/msg00017.html> There are valid reasons to avoid Github. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: (ITS#8827) lmdb from master fails to build with Visual Studio 2015.
by rion4ik＠gmail.com 29 Mar '18

29 Mar '18

--000000000000ac244b056892dafb Content-Type: text/plain; charset="UTF-8" logs: c:\src\lmdb\libraries\liblmdb\mdb.c(55): error C2059: syntax error: '(' 1>c:\src\lmdb\libraries\liblmdb\mdb.c(61): error C2143: syntax error: missing '{' before '*' 1>c:\src\lmdb\libraries\liblmdb\mdb.c(68): error C2059: syntax error: '(' 1>c:\src\lmdb\libraries\liblmdb\mdb.c(75): error C2143: syntax error: missing '{' before '*' 1>c:\src\lmdb\libraries\liblmdb\mdb.c(77): error C2059: syntax error: '(' 1>c:\src\lmdb\libraries\liblmdb\mdb.c(79): error C2143: syntax error: missing '{' before '*' 1>c:\src\lmdb\libraries\liblmdb\mdb.c(4339): error C2063: 'NtCreateSection': not a function 1>c:\src\lmdb\libraries\liblmdb\mdb.c(4346): error C2063: 'NtMapViewOfSection': not a function 1>c:\src\lmdb\libraries\liblmdb\mdb.c(4350): error C2063: 'NtClose': not a function 1>c:\src\lmdb\libraries\liblmdb\mdb.c(4704): error C2065: 'NtCloseFunc': undeclared identifier 1>c:\src\lmdb\libraries\liblmdb\mdb.c(4704): error C2059: syntax error: ')' 1>c:\src\lmdb\libraries\liblmdb\mdb.c(4707): error C2065: 'NtMapViewOfSectionFunc': undeclared identifier 1>c:\src\lmdb\libraries\liblmdb\mdb.c(4707): error C2059: syntax error: ')' 1>c:\src\lmdb\libraries\liblmdb\mdb.c(4710): error C2065: 'NtCreateSectionFunc': undeclared identifier 1>c:\src\lmdb\libraries\liblmdb\mdb.c(4710): error C2059: syntax error: ')' 1>c:\src\lmdb\libraries\liblmdb\mdb.c(8314): warning C4333: '>>': right shift by too large amount, data los PS github's bug tracker is much more user-friendly, it even has command line interface for old-school guys. Why do you use this mail-based crap? Best Regards, Sergey --000000000000ac244b056892dafb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr">logs:<div><br></div><div><div>c:\src\lmdb\libraries\liblmd= b\mdb.c(55): error C2059: syntax error: '('</div><div>1>c:\src\l= mdb\libraries\liblmdb\mdb.c(61): error C2143: syntax error: missing '{&= #39; before '*'</div><div>1>c:\src\lmdb\libraries\liblmdb\mdb.c(= 68): error C2059: syntax error: '('</div><div>1>c:\src\lmdb\libr= aries\liblmdb\mdb.c(75): error C2143: syntax error: missing '{' bef= ore '*'</div><div>1>c:\src\lmdb\libraries\liblmdb\mdb.c(77): err= or C2059: syntax error: '('</div><div>1>c:\src\lmdb\libraries\li= blmdb\mdb.c(79): error C2143: syntax error: missing '{' before &#39= ;*'</div><div>1>c:\src\lmdb\libraries\liblmdb\mdb.c(4339): error C20= 63: 'NtCreateSection': not a function</div><div>1>c:\src\lmdb\li= braries\liblmdb\mdb.c(4346): error C2063: 'NtMapViewOfSection': not= a function</div><div>1>c:\src\lmdb\libraries\liblmdb\mdb.c(4350): error= C2063: 'NtClose': not a function</div><div>1>c:\src\lmdb\librar= ies\liblmdb\mdb.c(4704): error C2065: 'NtCloseFunc': undeclared ide= ntifier</div><div>1>c:\src\lmdb\libraries\liblmdb\mdb.c(4704): error C20= 59: syntax error: ')'</div><div>1>c:\src\lmdb\libraries\liblmdb\= mdb.c(4707): error C2065: 'NtMapViewOfSectionFunc': undeclared iden= tifier</div><div>1>c:\src\lmdb\libraries\liblmdb\mdb.c(4707): error C205= 9: syntax error: ')'</div><div>1>c:\src\lmdb\libraries\liblmdb\m= db.c(4710): error C2065: 'NtCreateSectionFunc': undeclared identifi= er</div><div>1>c:\src\lmdb\libraries\liblmdb\mdb.c(4710): error C2059: s= yntax error: ')'</div><div>1>c:\src\lmdb\libraries\liblmdb\mdb.c= (8314): warning C4333: '>>': right shift by too large amount,= data los</div></div><div class=3D"gmail_extra"><br></div><div class=3D"gma= il_extra">PS github's bug tracker is much more user-friendly, it even h= as command line interface for old-school guys. Why do you use this mail-bas= ed crap?</div><div class=3D"gmail_extra"><br clear=3D"all"><div><div class= =3D"gmail_signature" data-smartmail=3D"gmail_signature"><div dir=3D"ltr">Be= st Regards,<div>Sergey</div></div></div></div><br></div></div> --000000000000ac244b056892dafb--

1 0

(ITS#8827) lmdb from master fails to build with Visual Studio 2015.
by rion4ik＠gmail.com 29 Mar '18

29 Mar '18

Full_Name: Sergey Ilinykh Version: master OS: Windows URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (194.60.247.123) I proposed a fix which works for me here in a comment https://github.com/LMDB/lmdb/commit/e85ae1fe883b4847f07cfebc2630636d06e429c3 I can't provide logs right now, but it seems developers do not care anyway. So just to let you know.

1 0

(ITS#8826) Contrib dsaschema module needs updating for cn=config
by quanah＠openldap.org 28 Mar '18

28 Mar '18

Full_Name: Quanah Gibson-Mount Version: HEAD OS: N/A URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (47.208.148.239) The dsaschema contrib module needs updating so that it support cn=config

1 0

Re: (ITS#8825) slapo-memberof: memberof-memberof-ad doesn't work correctly
by quanah＠symas.com 28 Mar '18

28 Mar '18

--On Wednesday, March 28, 2018 1:14 AM +0100 Howard Chu <hyc(a)symas.com> wrote: > That's because memberOf is an operational attribute, so objectclass > requirements don't apply. If you want to use some other attribute, make > sure the schema allows it in the relevant entries, or use an operational > attribute. > > Not a bug. Closing this ITS. For historical purposes, it is a bit more complex than this. It is not possible to include an operational attribute via the normal schema methods. This depends on the "dsaschema" contrib overlay. That contrib overlay requires development to support cn=config. The alternative to using an operational attribute is to have a custom objectClass where the custom attribute desired is defined as an optional ("MAY") attribute. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: (ITS#8825) slapo-memberof: memberof-memberof-ad doesn't work correctly
by hyc＠symas.com 28 Mar '18

28 Mar '18

quanah(a)openldap.org wrote: > Full_Name: Quanah Gibson-Mount > Version: 2.4.45 > OS: Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (47.208.148.239) > > > Per the slapo-memberof man page, you can define a different attribute than > "memberOf" to hold the group membership information for an entry. > > However, this fails due to the fact that when a different attribute is used, > slapd applies objectClass rule requirements to the entry. slapd does *not* do > this when the default value of "memberOf" is used. That's because memberOf is an operational attribute, so objectclass requirements don't apply. If you want to use some other attribute, make sure the schema allows it in the relevant entries, or use an operational attribute. Not a bug. Closing this ITS. > > Example config: > > overlay memberof > memberof-group-oc groupofuniquenames > memberof-member-ad uniquemember > memberof-memberof-ad ismemberof > > Example schema: > > attributetype ( 2.15.930.3.234225.3.1 > NAME 'isMemberOf' > DESC 'Sun defined attribute type' > EQUALITY distinguishedNameMatch > SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 > X-ORIGIN 'Sun Directory Server' ) > > Create a group: > > dn: cn=mygroup,dc=example,dc=com > objectClass: top > objectClass: groupOfUniqueNames > cn: mygroup > uniqueMember: cn=La Valko,ou=Peons,dc=example,dc=com > > Group creates OK, but: > > slapd[5149]: Entry (cn=La Valko,ou=Peons,dc=example,dc=com), attribute > 'isMemberOf' not allowed > slapd[5149]: entry failed schema check: attribute 'isMemberOf' not allowed > slapd[5149]: conn=1000 op=19: memberof_value_modify DN="cn=la > valko,ou=peons,dc=example,dc=com" add isMemberOf="cn=mygroup,dc=example,dc=com" > failed err=65 > > > > -- -- 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#8825) slapo-memberof: memberof-memberof-ad doesn't work correctly
by quanah＠openldap.org 28 Mar '18

28 Mar '18

Full_Name: Quanah Gibson-Mount Version: 2.4.45 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (47.208.148.239) Per the slapo-memberof man page, you can define a different attribute than "memberOf" to hold the group membership information for an entry. However, this fails due to the fact that when a different attribute is used, slapd applies objectClass rule requirements to the entry. slapd does *not* do this when the default value of "memberOf" is used. Example config: overlay memberof memberof-group-oc groupofuniquenames memberof-member-ad uniquemember memberof-memberof-ad ismemberof Example schema: attributetype ( 2.15.930.3.234225.3.1 NAME 'isMemberOf' DESC 'Sun defined attribute type' EQUALITY distinguishedNameMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 X-ORIGIN 'Sun Directory Server' ) Create a group: dn: cn=mygroup,dc=example,dc=com objectClass: top objectClass: groupOfUniqueNames cn: mygroup uniqueMember: cn=La Valko,ou=Peons,dc=example,dc=com Group creates OK, but: slapd[5149]: Entry (cn=La Valko,ou=Peons,dc=example,dc=com), attribute 'isMemberOf' not allowed slapd[5149]: entry failed schema check: attribute 'isMemberOf' not allowed slapd[5149]: conn=1000 op=19: memberof_value_modify DN="cn=la valko,ou=peons,dc=example,dc=com" add isMemberOf="cn=mygroup,dc=example,dc=com" failed err=65

1 0

(ITS#8824) openldap-2.4.46/libraries/liblmdb/mdb_dump.c:136]: (style) Suspicious condition
by dcb314＠hotmail.com 26 Mar '18

26 Mar '18

Full_Name: David Binderman Version: 2.4.46 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (79.65.172.203) openldap-2.4.46/libraries/liblmdb/mdb_dump.c:136]: (style) Suspicious condition (assignment + comparison); Clarify expression with parentheses. Source code is while ((rc = mdb_cursor_get(mc, &key, &data, MDB_NEXT) == MDB_SUCCESS)) { maybe better code while ((rc = mdb_cursor_get(mc, &key, &data, MDB_NEXT)) == MDB_SUCCESS) {

1 0

Re: (ITS#8823) LMDB on ramdisk
by hyc＠symas.com 21 Mar '18

21 Mar '18

luca.foppiano(a)inria.fr wrote: > Full_Name: Luca Foppiano > Version: 2.4 > OS: linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (37.169.254.52) > > > Dear OpenLDAP team, > I'm using one of your component (LMDB) via a java JNDI bindings > implementation (https://github.com/deephacks/lmdbjni) and I'm having an issue > when I deploy my LMDB file on a tempfs filesystem in RAM. The ITS is for bug reports, not for help requests. Use the -technical mailing list. Closing this ITS. > > The issue do not occur when the LMDB files are stored on a "normal" filesystem. > When the data is in the tempfs ramdisk all the allocated memory ends up being in > the Dirty area (it has not been written back to the Filesytem). > > Here an example using the ramdisk: > > 7ce320000000-7cfc20000000 r--s 00000000 00:26 2459 > /ramfs/nerd/data/db/db-en/entityEmbeddings/data.mdb > Size: 104857600 kB > Rss: 1255680 kB > Pss: 1255680 kB > Shared_Clean: 0 kB > Shared_Dirty: 0 kB > Private_Clean: 0 kB > Private_Dirty: 1255680 kB <--- > Referenced: 1255680 kB > Anonymous: 0 kB > AnonHugePages: 0 kB > Shared_Hugetlb: 0 kB > Private_Hugetlb: 0 kB > Swap: 0 kB > SwapPss: 0 kB > KernelPageSize: 4 kB > MMUPageSize: 4 kB > Locked: 0 kB > VmFlags: rd sh mr mw me ms sd > > and here an example without: > > 7ca4fc000000-7cbdfc000000 r--s 00000000 fd:00 11154951 > /data/workspace/shared/nerd-data/db/db-en/entityEmbeddings/data.mdb > Size: 104857600 kB > Rss: 838124 kB > Pss: 838124 kB > Shared_Clean: 0 kB > Shared_Dirty: 0 kB > Private_Clean: 838124 kB <---- > Private_Dirty: 0 kB > Referenced: 764872 kB > Anonymous: 0 kB > AnonHugePages: 0 kB > ShmemPmdMapped: 0 kB > Shared_Hugetlb: 0 kB > Private_Hugetlb: 0 kB > Swap: 0 kB > SwapPss: 0 kB > KernelPageSize: 4 kB > MMUPageSize: 4 kB > Locked: 0 kB > VmFlags: rd sh mr mw me ms sd > > > According to my understanding the memory is dirty when 1)there are open > transactions, 2) the data has not been written back to the filesystem > > What I don't understand is why there is a difference between filesystem and > ramdisk? > Is there any reason? The application (listed above) is not writing on the lmdb, > but just reading (using reading transaction). > > Thank you > Luca > > -- -- 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#8823) LMDB on ramdisk
by luca.foppiano＠inria.fr 21 Mar '18

21 Mar '18

Full_Name: Luca Foppiano Version: 2.4 OS: linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (37.169.254.52) Dear OpenLDAP team, I'm using one of your component (LMDB) via a java JNDI bindings implementation (https://github.com/deephacks/lmdbjni) and I'm having an issue when I deploy my LMDB file on a tempfs filesystem in RAM. The issue do not occur when the LMDB files are stored on a "normal" filesystem. When the data is in the tempfs ramdisk all the allocated memory ends up being in the Dirty area (it has not been written back to the Filesytem). Here an example using the ramdisk: 7ce320000000-7cfc20000000 r--s 00000000 00:26 2459 /ramfs/nerd/data/db/db-en/entityEmbeddings/data.mdb Size: 104857600 kB Rss: 1255680 kB Pss: 1255680 kB Shared_Clean: 0 kB Shared_Dirty: 0 kB Private_Clean: 0 kB Private_Dirty: 1255680 kB <--- Referenced: 1255680 kB Anonymous: 0 kB AnonHugePages: 0 kB Shared_Hugetlb: 0 kB Private_Hugetlb: 0 kB Swap: 0 kB SwapPss: 0 kB KernelPageSize: 4 kB MMUPageSize: 4 kB Locked: 0 kB VmFlags: rd sh mr mw me ms sd and here an example without: 7ca4fc000000-7cbdfc000000 r--s 00000000 fd:00 11154951 /data/workspace/shared/nerd-data/db/db-en/entityEmbeddings/data.mdb Size: 104857600 kB Rss: 838124 kB Pss: 838124 kB Shared_Clean: 0 kB Shared_Dirty: 0 kB Private_Clean: 838124 kB <---- Private_Dirty: 0 kB Referenced: 764872 kB Anonymous: 0 kB AnonHugePages: 0 kB ShmemPmdMapped: 0 kB Shared_Hugetlb: 0 kB Private_Hugetlb: 0 kB Swap: 0 kB SwapPss: 0 kB KernelPageSize: 4 kB MMUPageSize: 4 kB Locked: 0 kB VmFlags: rd sh mr mw me ms sd According to my understanding the memory is dirty when 1)there are open transactions, 2) the data has not been written back to the filesystem What I don't understand is why there is a difference between filesystem and ramdisk? Is there any reason? The application (listed above) is not writing on the lmdb, but just reading (using reading transaction). Thank you Luca

1 0

Re: (ITS#8822) Conan package
by hyc＠symas.com 21 Mar '18

21 Mar '18

zamazan4ik(a)tut.by wrote: > Full_Name: Alexander Zaitsev > Version: None > OS: Linux > URL: > Submission from: (NULL) (128.140.241.11) > > > Hello, > Do you know about Conan(https://github.com/conan-io/conan)? > Conan is modern dependency manager for C++. And will be great if your library > will be available via package manager for other developers. > > On https://github.com/bincrafters/conan-templates) you can find example, how you > can create package for the library. > > If you have any questions, just ask :-) > > The OpenLDAP Project provides source code, not packages. Feel free to create whatever packages you want. Closing this ITS. -- -- 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#8822) Conan package
by zamazan4ik＠tut.by 21 Mar '18

21 Mar '18

Full_Name: Alexander Zaitsev Version: None OS: Linux URL: Submission from: (NULL) (128.140.241.11) Hello, Do you know about Conan(https://github.com/conan-io/conan)? Conan is modern dependency manager for C++. And will be great if your library will be available via package manager for other developers. On https://github.com/bincrafters/conan-templates) you can find example, how you can create package for the library. If you have any questions, just ask :-)

1 0

Re: (ITS#8821) memory leak during slap_send_ldap_result()
by hyc＠symas.com 21 Mar '18

21 Mar '18

valdemar.pavesi(a)nokia.com wrote: > Full_Name: VALDEMAR PAVESI > Version: 2.4.40 > OS: 3.10.0-514.26.2.el7.x86_64 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (131.228.48.70) > > > hello, > > during add an delete there is a memory leak. This could be ITS#8031 or ITS#8690. 2.4.40 is nearly 4 years old. Please use a newer release and report back if you're still seeing the problem. > got 1000 times memory leaked: > > > 0x00007fc8000f8f70 libc-2.17.so __malloc()+0 > 0x00007fc8017cf2b5 liblber-2.4.so ber_memalloc_x()+53 > 0x00007fc8017cf5de liblber-2.4.so ber_dupbv_x()+62 > 0x00007fc801ea1c23 slapd > 0x00007fc801ea2172 slapd attrs_dup()+66 > 0x00007fc801ea551b slapd entry_dup2()+75 > 0x00007fc7fc6f1403 syncprov-2.4.so > 0x00007fc7fc6f20c2 syncprov-2.4.so > 0x00007fc801ea91f3 slapd > 0x00007fc801ea97b0 slapd > 0x00007fc801eaa342 slapd slap_send_ldap_result()+114 > 0x00007fc801f1807d slapd bdb_modify()+1325 > 0x00007fc801f07926 slapd overlay_op_walk()+134 > 0x00007fc801f07a94 slapd > 0x00007fc801efe7bf slapd > 0x00007fc801f008eb slapd > 0x00007fc801e999a1 slapd > 0x00007fc8019e9fba libldap_r-2.4.so > 0x00007fc800caddc5 libpthread-2.17.so start_thread()+197 > 0x00007fc80017076d libc-2.17.so __clone()+109 > > +++++++++++++++++++++++++++++++++ -- -- 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#8821) memory leak during slap_send_ldap_result()
by valdemar.pavesi＠nokia.com 21 Mar '18

21 Mar '18

Full_Name: VALDEMAR PAVESI Version: 2.4.40 OS: 3.10.0-514.26.2.el7.x86_64 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (131.228.48.70) hello, during add an delete there is a memory leak. fsuseradd CESNAT4 -G _nokfsuipmgroot -p Gok9zt0Fy4FZYWhW/fGHLseWjPj/Dgv1 fsuserdel -r remove CESNAT4 there is a success for both commands. +++++++++++++++++++++++++++++++++++++++ memory keep increasing... Every 5.0s: ps -p 29064 o vsz,rss Wed Mar 21 02:34:22 2018 VSZ RSS 831368 83980 +++++++++++++++++++++++++++++++++ Every 5.0s: ps -p 29064 o vsz,rss Wed Mar 21 02:36:12 2018 VSZ RSS 831368 83984 +++++++++++++++++++++++++++++++++ got 1000 times memory leaked: 0x00007fc8000f8f70 libc-2.17.so __malloc()+0 0x00007fc8017cf2b5 liblber-2.4.so ber_memalloc_x()+53 0x00007fc8017cf5de liblber-2.4.so ber_dupbv_x()+62 0x00007fc801ea1c23 slapd 0x00007fc801ea2172 slapd attrs_dup()+66 0x00007fc801ea551b slapd entry_dup2()+75 0x00007fc7fc6f1403 syncprov-2.4.so 0x00007fc7fc6f20c2 syncprov-2.4.so 0x00007fc801ea91f3 slapd 0x00007fc801ea97b0 slapd 0x00007fc801eaa342 slapd slap_send_ldap_result()+114 0x00007fc801f1807d slapd bdb_modify()+1325 0x00007fc801f07926 slapd overlay_op_walk()+134 0x00007fc801f07a94 slapd 0x00007fc801efe7bf slapd 0x00007fc801f008eb slapd 0x00007fc801e999a1 slapd 0x00007fc8019e9fba libldap_r-2.4.so 0x00007fc800caddc5 libpthread-2.17.so start_thread()+197 0x00007fc80017076d libc-2.17.so __clone()+109 +++++++++++++++++++++++++++++++++ if keep running both commands, there is one time that we will get this error: # fsuseradd CESNAT -G _nokfsuipmgroot -p Gok9zt0Fy4FZYWhW/fGHLseWjPj/Dgv1 invalid parameter: CESNAT already exists. use -g option to assign user to CESNAT # fsuserdel -r remove CESNAT Username CESNAT does not exist in LDAP. # fsuseradd CESNAT -G _nokfsuipmgroot -p Gok9zt0Fy4FZYWhW/fGHLseWjPj/Dgv1 invalid parameter: CESNAT already exists. use -g option to assign user to CESNAT # fsuserdel -r remove CESNAT Username CESNAT does not exist in LDAP. # fsuserdel -r remove CESNAT Username CESNAT does not exist in LDAP. # fsuseradd CESNAT -G _nokfsuipmgroot -p Gok9zt0Fy4FZYWhW/fGHLseWjPj/Dgv1 invalid parameter: CESNAT already exists. use -g option to assign user to CESNAT +++++++++++++++++++++++++++++++++++++++++ [root@santos-santoscmm-necc0 ~]# more /opt/aaa/ldap/conf/ldap.conf # $OpenLDAP: pkg/ldap/servers/slapd/slapd.conf,v 1.8.8.7 2001/09/27 20:00:31 kurt Exp $ # # See slapd.conf(5) for details on configuration options. # This file should NOT be world readable. # include /opt/aaa/ldap/schema/fsAll.schema #schemacheck off # Do not enable referrals until AFTER you have a working directory # service AND an understanding of referrals. #referral ldap://root.openldap.org pidfile /var/run/slapd/slapd.pid #argsfile /var/run/openldap/slapd.args # Load dynamic backend modules: # modulepath /usr/local/libexec/openldap # moduleload back_ldap.la # moduleload back_ldbm.la # moduleload back_passwd.la # moduleload back_shell.la # Define global ACLs to disable default read access. include /opt/aaa/ldap/conf/security.conf allows bind_v2 # Log level here doesn't really have any effect since the service is started with -d option loglevel 256 logfile /var/log/ldap/ldap.log # Set the max size of primary thread pool threads 20 ####################################################################### # ldbm database definitions ####################################################################### sizelimit unlimited # main database ####################################################### database bdb suffix "" rootdn "fsClusterId=ClusterRoot" rootpw {CRYPT}$6$cKyVbTD/bEiX$DOOeUCXHkmOTdlbRq0n.hGzgv7rhD2MG4.hAt8s.8Gqr73gUKw7swD2xR7zvidcfpvbkVjOkruY4BM9UprSFH/ password-hash {CRYPT} password-crypt-salt-format "$6$%.12s" checkpoint 1024 60 directory /var/lib/ldap/aaa index objectClass,entryCSN,entryUUID eq index uid,uidNumber,gidNumber,fssecAssignedGroupRoleRef,memberUid eq moduleload /usr/lib64/openldap/ppolicy.la overlay ppolicy ppolicy_default "fsFragmentId=Policy,fsFragmentId=Configurations,fsFragmentId=Security,fsClusterId=ClusterRoot" #overlay glue #cachesize 30000 TLSCertificateFile local.local security ssf=128 TLSCipherSuite HIGH:TLS_RSA_WITH_AES_128_CBC_SHA:TLS_RSA_WITH_AES_256_CBC_SHA:-SSLv2:-SSLv3 TLSCACertificatePath /etc/openldap/internal_certs TLSVerifyClient never include /opt/nokia/aaa/ldap/conf/sync.conf # +++++++++++++++++++++++++++++++++++++++++ regards! Valdemar

1 0

Re: (ITS#8819) LMDB seg fault with MDB_DUPSORT on -O3
by hyc＠symas.com 20 Mar '18

20 Mar '18

nic(a)nicwatson.org wrote: > That's news to me. Then I googled it. You're right. > >>From https://wiki.sei.cmu.edu/confluence/display/c/EXP36-C.+Do+not+cast+pointers… > > The C Standard, 6.3.2.3, paragraph 7 [ISO/IEC 9899:2011], states > > A pointer to an object or incomplete type may be converted to a > pointer to a different object or incomplete type. If the resulting > pointer is not correctly aligned for the referenced type, the behavior > is undefined. > > Nic > > On Tue, Mar 20, 2018 at 9:41 AM, Hallvard Breien Furuseth > <h.b.furuseth(a)usit.uio.no> wrote: >> Looks like another type aliasing problem to me. The data is accessed >> through an MDB_page* variable. This tells the compiler that the data >> is word-aligned, like struct MDB_page. Fix: Use a void/char pointer, >> don't lie to the compiler. Good catch. We once discussed padding odd-length keys to make sure the data was still word-aligned. Maybe should do that in LMDB 1.0. This particular crash is now fixed in mdb.master. I've left other derefs of *fp alone for the moment but may need to revisit that later; older ARM and SPARC would probably choke on them. -- -- 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#8819) LMDB seg fault with MDB_DUPSORT on -O3
by nic＠nicwatson.org 20 Mar '18

20 Mar '18

That's news to me. Then I googled it. You're right. >From https://wiki.sei.cmu.edu/confluence/display/c/EXP36-C.+Do+not+cast+pointers… The C Standard, 6.3.2.3, paragraph 7 [ISO/IEC 9899:2011], states A pointer to an object or incomplete type may be converted to a pointer to a different object or incomplete type. If the resulting pointer is not correctly aligned for the referenced type, the behavior is undefined. Nic On Tue, Mar 20, 2018 at 9:41 AM, Hallvard Breien Furuseth <h.b.furuseth(a)usit.uio.no> wrote: > Looks like another type aliasing problem to me. The data is accessed > through an MDB_page* variable. This tells the compiler that the data > is word-aligned, like struct MDB_page. Fix: Use a void/char pointer, > don't lie to the compiler. >

1 0

Re: (ITS#8819) LMDB seg fault with MDB_DUPSORT on -O3
by h.b.furuseth＠usit.uio.no 20 Mar '18

20 Mar '18

Looks like another type aliasing problem to me. The data is accessed through an MDB_page* variable. This tells the compiler that the data is word-aligned, like struct MDB_page. Fix: Use a void/char pointer, don't lie to the compiler.

1 0

Re: (ITS#8819) LMDB seg fault with MDB_DUPSORT on -O3
by nic＠nicwatson.org 20 Mar '18

20 Mar '18

--000000000000b2e0cc0567d7decb Content-Type: text/plain; charset="UTF-8" Summary of findings so far: Attached is a make script that applies the minimal set of optimizations (at least on gcc 7) that still triggers the seg fault. It fails the first time that address is executed, when NUMKEYS(fp) hits 10 or 11 (I *think* depending on the alignment of fp). It looks like the autovectorization logic is split in three parts: one unaligned non-SSE copy, an aligned copy that uses SSE, and then an unaligned non-SSE copy. It makes sense that the SSE logic path is only triggered when the size is greater than some threshold. We should coordinate filing a gcc bug report. Nic Watson On Fri, Mar 16, 2018 at 3:11 PM, <openldap-its(a)openldap.org> wrote: > > *** THIS IS AN AUTOMATICALLY GENERATED REPLY *** > > Thanks for your report to the OpenLDAP Issue Tracking System. Your > report has been assigned the tracking number ITS#8819. > > One of our support engineers will look at your report in due course. > Note that this may take some time because our support engineers > are volunteers. They only work on OpenLDAP when they have spare > time. > > If you need to provide additional information in regards to your > issue report, you may do so by replying to this message. Note that > any mail sent to openldap-its(a)openldap.org with (ITS#8819) > in the subject will automatically be attached to the issue report. > > mailto:openldap-its@openldap.org?subject=(ITS#8819) > > You may follow the progress of this report by loading the following > URL in a web browser: > http://www.OpenLDAP.org/its/index.cgi?findid=8819 > > Please remember to retain your issue tracking number (ITS#8819) > on any further messages you send to us regarding this report. If > you don't then you'll just waste our time and yours because we > won't be able to properly track the report. > > Please note that the Issue Tracking System is not intended to > be used to seek help in the proper use of OpenLDAP Software. > Such requests will be closed. > > OpenLDAP Software is user supported. > http://www.OpenLDAP.org/support/ > > -------------- > Copyright 1998-2007 The OpenLDAP Foundation, All Rights Reserved. > --000000000000b2e0cc0567d7decb Content-Type: application/x-shellscript; name="make.sh" Content-Disposition: attachment; filename="make.sh" Content-Transfer-Encoding: base64 X-Attachment-Id: f_jezny59e0 TE1EQl9ESVI9fi9zcmMvbG1kYi9saWJyYXJpZXMvbGlibG1kYgoKCk5PT1BUUzE9IgotZm5vLWF1 dG8taW5jLWRlYwotZm5vLWJyYW5jaC1jb3VudC1yZWcKLWZuby1jb21iaW5lLXN0YWNrLWFkanVz dG1lbnRzCi1mbm8tY29tcGFyZS1lbGltCi1mbm8tY3Byb3AtcmVnaXN0ZXJzCi1mbm8tZGNlCi1m bm8tZGVmZXItcG9wCi1mbm8tZGVsYXllZC1icmFuY2gKLWZuby1kc2UKLWZuby1mb3J3YXJkLXBy b3BhZ2F0ZQotZm5vLWd1ZXNzLWJyYW5jaC1wcm9iYWJpbGl0eQotZm5vLWlmLWNvbnZlcnNpb24y Ci1mbm8taWYtY29udmVyc2lvbgotZm5vLWlubGluZS1mdW5jdGlvbnMtY2FsbGVkLW9uY2UKLWZu by1pcGEtcHVyZS1jb25zdAotZm5vLWlwYS1wcm9maWxlCi1mbm8taXBhLXJlZmVyZW5jZQotZm5v LW1lcmdlLWNvbnN0YW50cwotZm5vLW1vdmUtbG9vcC1pbnZhcmlhbnRzCi1mbm8tb21pdC1mcmFt ZS1wb2ludGVyCi1mbm8tcmVvcmRlci1ibG9ja3MKLWZuby1zaHJpbmstd3JhcAotZm5vLXNocmlu ay13cmFwLXNlcGFyYXRlCi1mbm8tc3BsaXQtd2lkZS10eXBlcwotZm5vLXNzYS1iYWNrcHJvcAot Zm5vLXNzYS1waGlvcHQKLWZuby10cmVlLWJpdC1jY3AKLWZuby10cmVlLWNjcAotZm5vLXRyZWUt Y29hbGVzY2UtdmFycwotZm5vLXRyZWUtY29weS1wcm9wCi1mbm8tdHJlZS1kY2UKLWZuby10cmVl LWRvbWluYXRvci1vcHRzCi1mbm8tdHJlZS1kc2UKLWZuby10cmVlLWZvcndwcm9wCi1mbm8tdHJl ZS1waGlwcm9wCi1mbm8tdHJlZS1zaW5rCi1mbm8tdHJlZS1zbHNyCi1mbm8tdHJlZS1zcmEKLWZu by10cmVlLXB0YQotZm5vLXRyZWUtdGVyCi1mbm8tdW5pdC1hdC1hLXRpbWUKLWZ0cmVlLWZyZQot ZnRyZWUtY2gKIgojIE5vdGUgbGFzdCBlbnRyeSBpcyAqbm90KiBkaXNhYmxlZAoKT1BUUzI9Jwot ZnN0cmljdC1hbGlhc2luZwonCgpybSBtZGJfY19leGUKZ2NjIC1PICROT09QVFMxICRPUFRTMiAt ZnRyZWUtdmVjdG9yaXplIC1mdmVjdC1jb3N0LW1vZGVsPXVubGltaXRlZCAtZ2dkYiAtc3RkPWMx MSAtV2FsbCAtSSAkTE1EQl9ESVIgIGxtZGJfY3Jhc2gyLmMgJExNREJfRElSL3ttZGIuYyxtaWRs LmN9IC1scHRocmVhZCAtbyBtZGJfY19leGUKcm0gLXIgZm9vLmxtZGIKbWtkaXIgLXAgZm9vLmxt ZGIK --000000000000b2e0cc0567d7decb--

1 0

Re: (ITS#8820) ldap_get_attribute_ber() return NULL pointer while OK
by daniel＠haxx.se 18 Mar '18

18 Mar '18

On Sun, 18 Mar 2018, Howard Chu wrote: > Looking at the mitigation you've applied, I'm not sure it's correct. In > particular, you're terminating the loop when you receive a NULL value, but > there may actually be multiple attributes present (with no values on any of > them) and you ought to continue iterating through them all. ... which is why my issue here is about the lack of documentation for the function! I tried to read up on how its supposed to work but I couldn't find any docs anywhere. -- / daniel.haxx.se

1 0

Re: (ITS#8820) ldap_get_attribute_ber() return NULL pointer while OK
by hyc＠symas.com 18 Mar '18

18 Mar '18

daniel(a)haxx.se wrote: > Full_Name: Daniel Stenberg > Version: any > OS: Linux > URL: > Submission from: (NULL) (178.174.211.173) > > > The function ldap_get_attribute_ber() is called to get attributes, but it turns > out that it can return LDAP_SUCCESS and still return a NULL pointer in the > result pointer when getting a particularly crafted response. > > This was a surprise to us and to curl, as this caused us a security > vulnerability. See https://curl.haxx.se/docs/adv_2018-97a2.html > > 1. There's no man page nor online resource to read the docs for this function so > its really hard to figure out this fact. > > 2. This behavior is surprising, and this flaw was even written by someone very > familiar with OpenLDAP, indicating it is unintended or at least not the normal > path. It's actually normal; if you issue a search and specify attrsonly, the results will only contain attribute names and no values. (e.g. using ldapsearch -A) As such, returning LDAP_SUCCESS with a NULL value is correct. Unfortunate oversight on my part when writing that curl patch. Looking at the mitigation you've applied, I'm not sure it's correct. In particular, you're terminating the loop when you receive a NULL value, but there may actually be multiple attributes present (with no values on any of them) and you ought to continue iterating through them all. > 3. Due to the above two points, I believe there's a risk curl is not the only > application in the world that had this bad assumption and thus this might be a > lurking security issue in more projects. > > / Daniel > > > -- -- 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#8820) ldap_get_attribute_ber() return NULL pointer while OK
by daniel＠haxx.se 17 Mar '18

17 Mar '18

Full_Name: Daniel Stenberg Version: any OS: Linux URL: Submission from: (NULL) (178.174.211.173) The function ldap_get_attribute_ber() is called to get attributes, but it turns out that it can return LDAP_SUCCESS and still return a NULL pointer in the result pointer when getting a particularly crafted response. This was a surprise to us and to curl, as this caused us a security vulnerability. See https://curl.haxx.se/docs/adv_2018-97a2.html 1. There's no man page nor online resource to read the docs for this function so its really hard to figure out this fact. 2. This behavior is surprising, and this flaw was even written by someone very familiar with OpenLDAP, indicating it is unintended or at least not the normal path. 3. Due to the above two points, I believe there's a risk curl is not the only application in the world that had this bad assumption and thus this might be a lurking security issue in more projects. / Daniel

1 0

Re: (ITS#8819) LMDB seg fault with MDB_DUPSORT on -O3
by hyc＠symas.com 17 Mar '18

17 Mar '18

hyc(a)symas.com wrote: > github(a)nicwatson.org wrote: >> Full_Name: Nic Watson >> Version: LMDB v 0.9.21 >> OS: Ubuntu 17.04 >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (108.56.136.246) >> >> >> I'm getting a seg fault in using LMDB on a database opened with MDB_DUPSORT. >> >> Here's a minimal set of operations that will cause the problem: > >> It will *not* crash under debug. In fact, -O3 -fvect-cost-model=cheap will >> *not* crash. This makes some sense since it is crashing on an SSE instruction. >> >> I tried gcc versions (Ubuntu 7.2.0-8ubuntu3.2) and (Ubuntu 6.4.0-8ubuntu1) with >> the same result. I also tried with the mdb.master branch (0.9.70) with the same >> result. >> >> I'm not convinced this a fault in your code. It may be a gcc bug. > > Interesting. I've got gcc 5.4.0 on Ubuntu 16.04 here, and no crash. Also > rather puzzled that there's anything vectorizable in this code, that seems > pretty unlikely. > I take it back - was able to reproduce the crash with gcc 5.4.0. The crash is on this instruction 0x000000000040f26b <+4235>: add $0x1,%edi => 0x000000000040f26e <+4238>: movdqa (%rax,%rdx,1),%xmm1 0x000000000040f273 <+4243>: mov (%rsp),%rax 0x000000000040f277 <+4247>: paddw %xmm0,%xmm1 movdqa's description is "Move aligned packed integer values" and the values here are not aligned. (gdb) bt #0 0x000000000040f26e in mdb_cursor_put (mc=mc@entry=0x7fffffffdd00, key=key@entry=0x7fffffffe0e0, data=data@entry=0x7fffffffe1c0, flags=flags@entry=0) at mdb.c:7673 #1 0x0000000000411d64 in mdb_cursor_put (flags=0, data=0x7fffffffe1c0, key=0x7fffffffe0e0, mc=0x7fffffffdd00) at mdb.c:9867 #2 mdb_put (txn=0x61e680, dbi=2, key=key@entry=0x7fffffffe0e0, data=data@entry=0x7fffffffe1c0, flags=flags@entry=0) at mdb.c:9868 #3 0x0000000000401c13 in cause_crash () at its8819.c:53 #4 0x0000000000401991 in main (argc=<optimized out>, argv=<optimized out>) at its8819.c:72 (gdb) l 7668 memcpy(METADATA(mp), METADATA(fp), NUMKEYS(fp) * fp->mp_pad); 7669 } else { 7670 memcpy((char *)mp + mp->mp_upper + PAGEBASE, (char *)fp + fp->mp_upper + PAGEBASE, 7671 olddata.mv_size - fp->mp_upper - PAGEBASE); 7672 for (i=0; i<NUMKEYS(fp); i++) 7673 mp->mp_ptrs[i] = fp->mp_ptrs[i] + offset; 7674 } 7675 } 7676 7677 rdata = &xdata; In particular, the fp pointer is on an odd address. Basically the movdqa instruction is not valid for use here. -- -- 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#8819) LMDB seg fault with MDB_DUPSORT on -O3
by hyc＠symas.com 17 Mar '18

17 Mar '18

github(a)nicwatson.org wrote: > Full_Name: Nic Watson > Version: LMDB v 0.9.21 > OS: Ubuntu 17.04 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (108.56.136.246) > > > I'm getting a seg fault in using LMDB on a database opened with MDB_DUPSORT. > > Here's a minimal set of operations that will cause the problem: > It will *not* crash under debug. In fact, -O3 -fvect-cost-model=cheap will > *not* crash. This makes some sense since it is crashing on an SSE instruction. > > I tried gcc versions (Ubuntu 7.2.0-8ubuntu3.2) and (Ubuntu 6.4.0-8ubuntu1) with > the same result. I also tried with the mdb.master branch (0.9.70) with the same > result. > > I'm not convinced this a fault in your code. It may be a gcc bug. Interesting. I've got gcc 5.4.0 on Ubuntu 16.04 here, and no crash. Also rather puzzled that there's anything vectorizable in this code, that seems pretty unlikely. -- -- 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#8819) LMDB seg fault with MDB_DUPSORT on -O3
by github＠nicwatson.org 16 Mar '18

16 Mar '18

Full_Name: Nic Watson Version: LMDB v 0.9.21 OS: Ubuntu 17.04 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (108.56.136.246) I'm getting a seg fault in using LMDB on a database opened with MDB_DUPSORT. Here's a minimal set of operations that will cause the problem: #include <stdio.h> #include "lmdb.h" #define ARRAY_SIZE(array) (sizeof(array) / sizeof(*array)) void cause_crash() { MDB_env *env; MDB_txn *txn; MDB_dbi dbi; int rc; int line_fail = 0; MDB_val key = {.mv_size = 1, .mv_data = "a"}; MDB_val vals[] = { { .mv_size = 8, .mv_data = "\x00\x00\x00\x00\x00\x00\x00\x00" }, { .mv_size = 1, .mv_data = "\x05" }, { .mv_size = 1, .mv_data = "\t" }, { .mv_size = 1, .mv_data = "\r" }, { .mv_size = 1, .mv_data = "\x11" }, { .mv_size = 1, .mv_data = "\x15" }, { .mv_size = 1, .mv_data = "\x19" }, { .mv_size = 1, .mv_data = "\x1d" }, { .mv_size = 1, .mv_data = "!" }, { .mv_size = 1, .mv_data = "%" }, { .mv_size = 1, .mv_data = ")" }, { .mv_size = 1, .mv_data = "-" }, { .mv_size = 1, .mv_data = "1" }, { .mv_size = 1, .mv_data = "5" }, }; rc = mdb_env_create(&env); if (rc) { line_fail = __LINE__; goto fail; } rc = mdb_env_set_maxdbs(env, 2); if (rc) { line_fail = __LINE__; goto fail; } rc = mdb_env_open(env, "foo.lmdb", 0, 0777); if (rc) { line_fail = __LINE__; goto fail; } rc = mdb_txn_begin(env, NULL, 0, &txn); if (rc) { line_fail = __LINE__; goto fail; } rc = mdb_dbi_open(txn, "another_db", MDB_CREATE | MDB_DUPSORT, &dbi); if (rc) { line_fail = __LINE__; goto fail; } rc = mdb_txn_commit(txn); if (rc) { line_fail = __LINE__; goto fail; } rc = mdb_txn_begin(env, NULL, 0, &txn); if (rc) { line_fail = __LINE__; goto fail; } for (int i = 0; i < ARRAY_SIZE(vals); i++) { rc = mdb_put(txn, dbi, &key, &vals[i], 0); if (rc) { line_fail = __LINE__; goto fail; } } rc = mdb_txn_commit(txn); if (rc) { line_fail = __LINE__; goto fail; } mdb_dbi_close(env, dbi); mdb_env_close(env); return; fail: printf("Failed with error %d on line %d\n", rc, line_fail); } int main(int argc, char **argv) { printf("Running %s\n", MDB_VERSION_STRING); cause_crash(); printf("Didn't crash!\n"); return 0; } Here's a simple sh make script: LMDB_DIR=~/src/lmdb/libraries/liblmdb gcc-6 -O3 -ggdb -std=c11 -Wall -I $LMDB_DIR lmdb_crash2.c $LMDB_DIR/{mdb.c,midl.c} -lpthread -o mdb_c_exe mkdir -p foo.lmdb Here's a basic stack trace: Program received signal SIGSEGV, Segmentation fault. 0x000055555555ee7c in mdb_cursor_put (mc=mc@entry=0x7fffffffcfa0, key=key@entry=0x7fffffffd380, data=data@entry=0x7fffffffd460, flags=flags@entry=0) at /home/nic/src/lmdb/libraries/liblmdb/mdb.c:6792 6792 mp->mp_ptrs[i] = fp->mp_ptrs[i] + offset; (gdb) bt #0 0x000055555555ee7c in mdb_cursor_put (mc=mc@entry=0x7fffffffcfa0, key=key@entry=0x7fffffffd380, data=data@entry=0x7fffffffd460, flags=flags@entry=0) at /home/nic/src/lmdb/libraries/liblmdb/mdb.c:6792 #1 0x00005555555635d0 in mdb_cursor_put (flags=0, data=0x7fffffffd460, key=0x7fffffffd380, mc=0x7fffffffcfa0) at /home/nic/src/lmdb/libraries/liblmdb/mdb.c:8984 #2 mdb_put (txn=0x55555576e8d0, It will *not* crash under debug. In fact, -O3 -fvect-cost-model=cheap will *not* crash. This makes some sense since it is crashing on an SSE instruction. I tried gcc versions (Ubuntu 7.2.0-8ubuntu3.2) and (Ubuntu 6.4.0-8ubuntu1) with the same result. I also tried with the mdb.master branch (0.9.70) with the same result. I'm not convinced this a fault in your code. It may be a gcc bug.

1 0

Re: (ITS#8813) MDB_VL32 causes MDB_TXN_FULL
by markus＠greenrobot.de 14 Mar '18

14 Mar '18

--001a114390bed95e010567661549 Content-Type: text/plain; charset="UTF-8" Some more details: Transaction read only pages are running out in mdb_rpage_get(). MDB_txn. mt_rpages[0] is at 4096 and thus MDB_TXN_FULL is returned. This happens after around 100K mdb_cursor_del() calls. How can we get millions of deletes to work in a single transaction? It's an essential feature to us and I am happy to contribute under some guidance. So, here's my hope: given that the cleanup involves only consecutive keys, we could consider a bulk delete function (delete an entire range from position 1 to position 2). This should be much more efficient. Basically, for most of the data, there's no need to operate on the node level. Deleting entire leaf pages should be relatively simple (rebalance on the parent branch page)? Not sure if rebalancing could also cope with cutting off entire branches (superefficient if that would work). Thanks, Markus --001a114390bed95e010567661549 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <html><head><meta http-equiv=3D"Content-Type" content=3D"text/html; charset= =3Dus-ascii"><meta name=3D"Generator" content=3D"Microsoft Word 14 (filtere= d medium)"><style></style></head><body lang=3D"DE" link=3D"blue" vlink=3D"purple"><div cla= ss=3D"WordSection1"><p class=3D"MsoNormal"><span lang=3D"EN-US">Some more d= etails:</span></p><p class=3D"MsoNormal"><span lang=3D"EN-US">Transaction r= ead only pages are running out in mdb_rpage_get(). MDB_txn. mt_rpages[0] is= at 4096 and thus MDB_TXN_FULL is returned. This happens after around 100K = mdb_cursor_del() calls.</span></p><p class=3D"MsoNormal"><span lang=3D"EN-U= S"> </span></p><p class=3D"MsoNormal"><span lang=3D"EN-US">How can we get m= illions of deletes to work in a single transaction?</span></p><p class=3D"M= soNormal"><span lang=3D"EN-US">=C2=A0</span></p><p class=3D"MsoNormal"><spa= n lang=3D"EN-US">It's an essential feature to us and I am happy to cont= ribute under some guidance.</span></p><p class=3D"MsoNormal"><span lang=3D"= EN-US">=C2=A0</span></p><p class=3D"MsoNormal"><span lang=3D"EN-US">So, her= e's my hope: given that the cleanup involves only consecutive keys, we = could consider a bulk delete function (delete an entire range from position= 1 to position 2). This should be much more efficient. Basically, for most = of the data, there's no need to operate on the node level. Deleting ent= ire leaf pages should be relatively simple (rebalance on the parent branch = page)? Not sure if rebalancing could also cope with cutting off entire bran= ches (superefficient if that would work).</span></p><p class=3D"MsoNormal">= <span lang=3D"EN-US">=C2=A0</span></p><p class=3D"MsoNormal"><span lang=3D"= EN-US">Thanks,</span></p><p class=3D"MsoNormal"><span lang=3D"EN-US">Markus= </span></p></div></body></html> --001a114390bed95e010567661549--

1 0

Re: (ITS#8818) SASL_MECH is wrongly documented as user option
by cheimes＠redhat.com 14 Mar '18

14 Mar '18

On 2018-03-13 18:49, Howard Chu wrote: > It appears the doc is stale. The user-only attribute was removed from > SASL_MECH in ITS#4327 (commit 86d10729) and apparently the docs weren't > updated then. Thanks for your confirmation and fixing the documentation in f183b81a!

1 0

Re: (ITS#8818) SASL_MECH is wrongly documented as user option
by hyc＠symas.com 13 Mar '18

13 Mar '18

cheimes(a)redhat.com wrote: > Full_Name: Christian Heimes > Version: 2.4.45 > OS: Fedora > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (2001:16b8:601e:1c00:18cd:bce4:2531:fe3) > > > SASL_MECH is documented as "This is a user-only option" in man ldap.conf, > https://www.openldap.org/software/man.cgi?query=ldap.conf . User-only options > are documented as "Such options are ignored if present in the ldap.conf". > Contrary to the documentation, libldap loads SASL_MECH from global ldap.conf. We > discussed the issue in > https://github.com/freeipa/freeipa/pull/1470#issuecomment-372602434 > > Is this a documentation bug or an implementation bug? It appears the doc is stale. The user-only attribute was removed from SASL_MECH in ITS#4327 (commit 86d10729) and apparently the docs weren't updated then. -- -- 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#8818) SASL_MECH is wrongly documented as user option
by cheimes＠redhat.com 13 Mar '18

13 Mar '18

Full_Name: Christian Heimes Version: 2.4.45 OS: Fedora URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (2001:16b8:601e:1c00:18cd:bce4:2531:fe3) SASL_MECH is documented as "This is a user-only option" in man ldap.conf, https://www.openldap.org/software/man.cgi?query=ldap.conf . User-only options are documented as "Such options are ignored if present in the ldap.conf". Contrary to the documentation, libldap loads SASL_MECH from global ldap.conf. We discussed the issue in https://github.com/freeipa/freeipa/pull/1470#issuecomment-372602434 Is this a documentation bug or an implementation bug?

1 0

(ITS#8817) SQL scripts for Altibase Backend Database
by grace.bae＠altibase.com 09 Mar '18

09 Mar '18

Full_Name: Younghee Bae Version: 2.4.45 OS: Linux URL: ftp://ftp.openldap.org/incoming/altibase-180309.patch Submission from: (NULL) (222.112.181.231) I'd like to add SQL scripts that create metatables, test data, metadata for Altibase database to OpenLDAP. I copied rdbms_depend/oracle and modified them for Altibase database. And I fixed some meta-data that were not working.

1 0

Re: (ITS#8816) OpenLDAP - Embedded Prodcut or Stand-alone product
by michael＠stroeder.com 07 Mar '18

07 Mar '18

muthamma.appaiah(a)wellsfargo.com wrote: > Full_Name: Muthamma > Version: OpenLDAP latest > OS: > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (2620:160:e708:6::a) > > > Hi team, > > Could you confirm if the product OpenLDAP is a stand-alone product or embedded? > > If this comes bundled with any other product? ITS is only used for reporting bugs. Please ask such a question on the openldap-technical mailing list. And please do not file the same question several times. Ciao, Michael.

1 0

Re: (ITS#8812) OpenLDAP 2.4 Standalone or embedded
by michael＠stroeder.com 07 Mar '18

07 Mar '18

muthamma.appaiah(a)wellsfargo.com wrote: > Full_Name: Muthamma > Version: 2.4 and 2.3 > OS: > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (2620:160:e708:6::a) > > > Hi team, > > Could you confirm if the product OpenLDAP is a stand-alone product or embedded? ITS is only used for reporting bugs. Please ask such a question on the openldap-technical mailing list. Ciao, Michael.

1 0

(ITS#8816) OpenLDAP - Embedded Prodcut or Stand-alone product
by muthamma.appaiah＠wellsfargo.com 07 Mar '18

07 Mar '18

Full_Name: Muthamma Version: OpenLDAP latest OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (2620:160:e708:6::a) Hi team, Could you confirm if the product OpenLDAP is a stand-alone product or embedded? If this comes bundled with any other product?

1 0

RE: (ITS#8618) ldapsearch - unexpected behavior with
by andrew.lawrence＠siemens.com 07 Mar '18

07 Mar '18

Hi Alex, I was wrong. It is not the lack of port that causes it to fail. On the third line of the output below you can see the ldapsearch request wi= thout the port has tried to construct a uri by appending "ldap://" to anoth= er ldap uri. $ ldapsearch -x -d 255 -h ldap://localhost ldap_create ldap_url_parse_ext(ldap://ldap:%2F%2Flocalhost) ldap_err2string Could not create LDAP session handle for URI=3Dldap://ldap: %2F%2Flocalhost (-9): Bad parameter to an ldap routine If you also specify the port it does not try to append "ldap://" to the fro= nt of the hostname/uri. From an external point of view the behaviour is cor= rect in that the command fails but the internal behaviour of the code is no= t as intended. Andy -----Original Message----- From: Alexandre Rosenberg [mailto:arekkusu@r42.ch]=20 Sent: 04 March 2018 12:30 To: Lawrence, Andy (MO MM R&D UK IXL); openldap-its(a)OpenLDAP.org Subject: Re: (ITS#8618) ldapsearch - unexpected behavior with =20

1 0

(ITS#8815) aarch64 autoconf error
by stephane＠qnap.com 06 Mar '18

06 Mar '18

Full_Name: stephane guerithault Version: 2.4.45 OS: Xenial Ubuntu arm64 ( aarch64) URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (2a06:4282:6:6b00:b0e4:f061:db67:e31e) Open Ldap autoconf script need uptade to compile from Source on aarch64 architecture (arm64) Configuring OpenLDAP 2.4.45-Release ... checking build system type... build/config.guess: unable to guess system type This script, last modified 2010-09-24-OpenLDAP, has failed to recognize the operating system you are using. It is advised that you download the most up to date version of the config scripts from http://git.savannah.gnu.org/gitweb/?p=config.git;a=blob_plain;f=config.gues… and http://git.savannah.gnu.org/gitweb/?p=config.git;a=blob_plain;f=config.sub;… If the version you run (build/config.guess) is already up to date, please send the following data and any information you think might be pertinent to <config-patches(a)gnu.org> in order to provide the needed information to handle your system. config.guess timestamp = 2010-09-24-OpenLDAP uname -m = aarch64 uname -r = 4.2.8 uname -s = Linux uname -v = #1 SMP Thu Feb 15 01:39:52 CST 2018 /usr/bin/uname -p = /bin/uname -X = hostinfo = /bin/universe = /usr/bin/arch -k = /bin/arch = /usr/bin/oslevel = /usr/convex/getsysinfo = UNAME_MACHINE = aarch64 UNAME_RELEASE = 4.2.8 UNAME_SYSTEM = Linux UNAME_VERSION = #1 SMP Thu Feb 15 01:39:52 CST 2018 configure: error: cannot guess build type; you must specify one root@TS-128A:/SRC/openldap-2.4.45# uname -a Linux TS-128A 4.2.8 #1 SMP Thu Feb 15 01:39:52 CST 2018 aarch64 aarch64 aarch64 GNU/Linux

1 0

(ITS#8814) aarch64 autoconf error
by stephane＠qnap.com 06 Mar '18

06 Mar '18

Full_Name: stephane guerithault Version: 2.4.45 OS: Xenial Ubuntu arm64 ( aarch64) URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (2a06:4282:6:6b00:b0e4:f061:db67:e31e) Open Ldap autoconf script need uptade to compile from Source on aarch64 architecture (arm64) Configuring OpenLDAP 2.4.45-Release ... checking build system type... build/config.guess: unable to guess system type This script, last modified 2010-09-24-OpenLDAP, has failed to recognize the operating system you are using. It is advised that you download the most up to date version of the config scripts from http://git.savannah.gnu.org/gitweb/?p=config.git;a=blob_plain;f=config.gues… and http://git.savannah.gnu.org/gitweb/?p=config.git;a=blob_plain;f=config.sub;… If the version you run (build/config.guess) is already up to date, please send the following data and any information you think might be pertinent to <config-patches(a)gnu.org> in order to provide the needed information to handle your system. config.guess timestamp = 2010-09-24-OpenLDAP uname -m = aarch64 uname -r = 4.2.8 uname -s = Linux uname -v = #1 SMP Thu Feb 15 01:39:52 CST 2018 /usr/bin/uname -p = /bin/uname -X = hostinfo = /bin/universe = /usr/bin/arch -k = /bin/arch = /usr/bin/oslevel = /usr/convex/getsysinfo = UNAME_MACHINE = aarch64 UNAME_RELEASE = 4.2.8 UNAME_SYSTEM = Linux UNAME_VERSION = #1 SMP Thu Feb 15 01:39:52 CST 2018 configure: error: cannot guess build type; you must specify one root@TS-128A:/SRC/openldap-2.4.45# uname -a Linux TS-128A 4.2.8 #1 SMP Thu Feb 15 01:39:52 CST 2018 aarch64 aarch64 aarch64 GNU/Linux

1 0

Re: (ITS#8777) [LMDB] Closing read cursor uses already freed transaction (MDB_VL32)
by markus＠greenrobot.de 04 Mar '18

04 Mar '18

--001a114db4265d5f2405669693c3 Content-Type: text/plain; charset="UTF-8" Because of another MDB_VL32 issue ( http://www.openldap.org/its/index.cgi?findid=8813), I would like to come back the MDB_SIZE64 patch suggested here. I understand that you have no intention to merge this in. For us, applying the patch makes perfectly sense nevertheless: It fixes a severe problem and the 2 GB limit on 32 bits is fine for our use case. Do you see any side effects the proposed patch might have? I'm aware you cannot give guarantees, but a simple "should work" from your side would be appreciated! Thanks! Markus I'd like to propose a different approach to 64 bits on 32 bit CPUs; > something like this: > [...] > lmdb.h > @@ -187,7 +187,15 @@ > # define MDB_FMT_Z "z" /**< printf/scanf format > modifier for size_t */ > #endif > > -#ifndef MDB_VL32 > +#if defined(MDB_VL32) && defined(MDB_SIZE64) > +#error either define MDB_VL32 OR MDB_SIZE64 > +#endif > +#ifdef MDB_SIZE64 > +typedef uint64_t mdb_size_t; > +# define MDB_SIZE_MAX SIZE_MAX /**< max #mdb_size_t */ > +# define MDB_PRIy(t) PRI##t##64 > +# define MDB_SCNy(t) SCN##t##64 > +#elif !defined(MDB_VL32)) > /** Unsigned type used for mapsize, entry counts and page/transaction IDs. > * > * It is normally size_t, hence the name. Defining MDB_VL32 makes it > --001a114db4265d5f2405669693c3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><div= >Because of another=C2=A0<span style=3D"color:rgb(34,34,34);font-family:ari= al,sans-serif;font-size:small;font-style:normal;font-variant-ligatures:norm= al;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-alig= n:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing= :0px;background-color:rgb(255,255,255);text-decoration-style:initial;text-d= ecoration-color:initial;float:none;display:inline">MDB_VL32 issue (<a href= =3D"http://www.openldap.org/its/index.cgi?findid=3D8813">http://www.openlda= p.org/its/index.cgi?findid=3D8813</a>), I would like to come back the=C2=A0= <span style=3D"color:rgb(34,34,34);font-family:arial,sans-serif;font-size:s= mall;font-style:normal;font-variant-ligatures:normal;font-variant-caps:norm= al;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;t= ext-transform:none;white-space:normal;word-spacing:0px;background-color:rgb= (255,255,255);text-decoration-style:initial;text-decoration-color:initial;f= loat:none;display:inline">MDB_SIZE64 patch <span style=3D"color:rgb(34,34,3= 4);font-family:arial,sans-serif;font-size:small;font-style:normal;font-vari= ant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacin= g:normal;text-align:start;text-indent:0px;text-transform:none;white-space:n= ormal;word-spacing:0px;background-color:rgb(255,255,255);text-decoration-st= yle:initial;text-decoration-color:initial;float:none;display:inline">sugges= ted<span>=C2=A0</span></span>here.</span></span></div><div><span style=3D"c= olor:rgb(34,34,34);font-family:arial,sans-serif;font-size:small;font-style:= normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:4= 00;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:no= ne;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);te= xt-decoration-style:initial;text-decoration-color:initial;float:none;displa= y:inline"><span style=3D"color:rgb(34,34,34);font-family:arial,sans-serif;f= ont-size:small;font-style:normal;font-variant-ligatures:normal;font-variant= -caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-in= dent:0px;text-transform:none;white-space:normal;word-spacing:0px;background= -color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color= :initial;float:none;display:inline"><br></span></span></div><div><span styl= e=3D"color:rgb(34,34,34);font-family:arial,sans-serif;font-size:small;font-= style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-we= ight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transf= orm:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,2= 55);text-decoration-style:initial;text-decoration-color:initial;float:none;= display:inline"><span style=3D"color:rgb(34,34,34);font-family:arial,sans-s= erif;font-size:small;font-style:normal;font-variant-ligatures:normal;font-v= ariant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;t= ext-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;back= ground-color:rgb(255,255,255);text-decoration-style:initial;text-decoration= -color:initial;float:none;display:inline">I understand that you have no int= ention to merge this in. For us, applying the patch makes perfectly sense n= evertheless: It fixes a severe problem and the 2 GB limit on 32 bits is fin= e for our use case.=C2=A0</span></span></div><div><span style=3D"color:rgb(= 34,34,34);font-family:arial,sans-serif;font-size:small;font-style:normal;fo= nt-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter= -spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-= space:normal;word-spacing:0px;background-color:rgb(255,255,255);text-decora= tion-style:initial;text-decoration-color:initial;float:none;display:inline"= ><span style=3D"color:rgb(34,34,34);font-family:arial,sans-serif;font-size:= small;font-style:normal;font-variant-ligatures:normal;font-variant-caps:nor= mal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;= text-transform:none;white-space:normal;word-spacing:0px;background-color:rg= b(255,255,255);text-decoration-style:initial;text-decoration-color:initial;= float:none;display:inline"><br></span></span></div><div><span style=3D"colo= r:rgb(34,34,34);font-family:arial,sans-serif;font-size:small;font-style:nor= mal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;= letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;= white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);text-= decoration-style:initial;text-decoration-color:initial;float:none;display:i= nline"><span style=3D"color:rgb(34,34,34);font-family:arial,sans-serif;font= -size:small;font-style:normal;font-variant-ligatures:normal;font-variant-ca= ps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-inden= t:0px;text-transform:none;white-space:normal;word-spacing:0px;background-co= lor:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:in= itial;float:none;display:inline">Do you see any side effects the proposed p= atch might have? I'm aware you cannot give guarantees, but a simple &qu= ot;should work" from your side would be appreciated!</span></span></di= v><div><span style=3D"color:rgb(34,34,34);font-family:arial,sans-serif;font= -size:small;font-style:normal;font-variant-ligatures:normal;font-variant-ca= ps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-inden= t:0px;text-transform:none;white-space:normal;word-spacing:0px;background-co= lor:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:in= itial;float:none;display:inline"><span style=3D"color:rgb(34,34,34);font-fa= mily:arial,sans-serif;font-size:small;font-style:normal;font-variant-ligatu= res:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;t= ext-align:start;text-indent:0px;text-transform:none;white-space:normal;word= -spacing:0px;background-color:rgb(255,255,255);text-decoration-style:initia= l;text-decoration-color:initial;float:none;display:inline"><br></span></spa= n></div><div><span style=3D"color:rgb(34,34,34);font-family:arial,sans-seri= f;font-size:small;font-style:normal;font-variant-ligatures:normal;font-vari= ant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text= -indent:0px;text-transform:none;white-space:normal;word-spacing:0px;backgro= und-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-co= lor:initial;float:none;display:inline"><span style=3D"color:rgb(34,34,34);f= ont-family:arial,sans-serif;font-size:small;font-style:normal;font-variant-= ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:no= rmal;text-align:start;text-indent:0px;text-transform:none;white-space:norma= l;word-spacing:0px;background-color:rgb(255,255,255);text-decoration-style:= initial;text-decoration-color:initial;float:none;display:inline">Thanks!</s= pan></span></div><div><span style=3D"color:rgb(34,34,34);font-family:arial,= sans-serif;font-size:small;font-style:normal;font-variant-ligatures:normal;= font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:s= tart;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0p= x;background-color:rgb(255,255,255);text-decoration-style:initial;text-deco= ration-color:initial;float:none;display:inline"><span style=3D"color:rgb(34= ,34,34);font-family:arial,sans-serif;font-size:small;font-style:normal;font= -variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-s= pacing:normal;text-align:start;text-indent:0px;text-transform:none;white-sp= ace:normal;word-spacing:0px;background-color:rgb(255,255,255);text-decorati= on-style:initial;text-decoration-color:initial;float:none;display:inline">M= arkus</span></span></div><div><span style=3D"color:rgb(34,34,34);font-famil= y:arial,sans-serif;font-size:small;font-style:normal;font-variant-ligatures= :normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text= -align:start;text-indent:0px;text-transform:none;white-space:normal;word-sp= acing:0px;background-color:rgb(255,255,255);text-decoration-style:initial;t= ext-decoration-color:initial;float:none;display:inline"><span style=3D"colo= r:rgb(34,34,34);font-family:arial,sans-serif;font-size:small;font-style:nor= mal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;= letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;= white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);text-= decoration-style:initial;text-decoration-color:initial;float:none;display:i= nline"><br></span></span></div><div><br></div><blockquote class=3D"gmail_qu= ote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,20= 4);padding-left:1ex">I'd like to propose a different approach to 64 bit= s on 32 bit CPUs;<br> something like this:<br>[...]<br>lmdb.h<br> @@ -187,7 +187,15 @@<br> =C2=A0# define MDB_FMT_Z=C2=A0 =C2=A0 =C2=A0"z"=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0/**< printf/s= canf format modifier for size_t */<br> =C2=A0#endif<br> <br> -#ifndef MDB_VL32<br> +#if defined(MDB_VL32) && defined(MDB_SIZE64)<br> +#error either define MDB_VL32 OR MDB_SIZE64<br> +#endif<br> +#ifdef MDB_SIZE64<br> +typedef uint64_t=C2=A0 =C2=A0 =C2=A0 =C2=A0mdb_size_t;<br> +# define MDB_SIZE_MAX=C2=A0 SIZE_MAX=C2=A0 =C2=A0 =C2=A0 =C2=A0 /**< ma= x #mdb_size_t */<br> +# define MDB_PRIy(t)=C2=A0 =C2=A0PRI##t##64<br> +# define MDB_SCNy(t)=C2=A0 =C2=A0SCN##t##64<br> +#elif !defined(MDB_VL32))<br> =C2=A0/** Unsigned type used for mapsize, entry counts and page/transaction= IDs.<br> =C2=A0 *<br> =C2=A0 *=C2=A0 =C2=A0 =C2=A0It is normally size_t, hence the name. Defining= MDB_VL32 makes it<br> </blockquote></div><br></div></div> --001a114db4265d5f2405669693c3--

1 0

(ITS#8813) MDB_VL32 causes MDB_TXN_FULL
by markus＠greenrobot.de 04 Mar '18

04 Mar '18

Full_Name: Markus Junginger Version: OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (77.189.91.168) We have a 1GB LMDB file with 7M K/V entries. With MDB_VL32, we always get a MDB_TXN_FULL error for a transaction that is removing 2M entries (probably fails at a lower count, we haven't measured that). Without MDB_VL32 it works fine. Another observation: Once the transaction fails with MDB_TXN_FULL, the data file has grown to 1.5GB. Without MDB_VL32, the data file stays consistent at 1 GB even if all 7M entries are deleted in a single transaction. Expected behavior: No MDB_TXN_FULL error, no data file growth.

1 0

Re: (ITS#8618) ldapsearch - unexpected behavior with
by arekkusu＠r42.ch 04 Mar '18

04 Mar '18

Andry, I am sorry but I still don't understand... - You are saying ldapsearch internally converts '-h' and '-p' parameters into a URI, correct ? - The '-p' option in ldapsearch is optional, if it's not set it should use the default LDAP port (TCP/389). In the example bellow, when I am calling ldapsearch without specifying the port (1), it does not say anything about the ldap URI being invalid. It simply tries to connect to '/example.org:389' and fails. (which is expected). On the other hand the same example with the option '-p 389' added, result in the query going to localhost (2). I don't understand why. The default LDAP port is TCP/389, therefore I would expect ldapsearch to behave in the same way regardless if the '-p 389' argument is provided or not. (1) $ ldapsearch -x -d 255 -h /example.org ldap_create ldap_url_parse_ext(ldap://% 2Fexample.org) ldap_sasl_bind ldap_send_initial_request ldap_new_connection 1 1 0 ld ap_int_open_connection ldap_connect_to_host: TCP /example.org:389 ldap_connect_to_ host: getaddrinfo failed: Name or service not known ldap_err2string ldap_sasl_bind (SIMPLE): Can't contact LDAP server (-1) (2) $ ldapsearch -x -d 255 -h /example.org -p 389 ldap_create ldap_sasl_bind ldap_send_initial_request ldap_new_connection 1 1 0 ldap_int_open_connection ldap_connect_to_host: TCP localhost:389 ldap_new_socket: 3 ldap_prepare_socket: 3 ldap_connect_to_host: Trying ::1 389 ldap_pvt_connect: fd: 3 tm: -1 async: 0 attempting to connect: connect errno: 111 ldap_close_socket: 3 ldap_new_socket: 3 ldap_prepare_socket: 3 ldap_connect_to_host: Trying 127.0.0.1:389 ldap_pvt_connect: fd: 3 tm: -1 async: 0 attempting to connect: connect errno: 111 ldap_close_socket: 3 ldap_err2string ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1) Best, Alex On Sat, 2018-03-03 at 16:24 +0000, andrew.lawrence(a)siemens.com wrote: > @Alex The difference in behaviour is because it constructs a uri from the h= > ostname and port. If there is no port you end up with an invalid uri. I am = > not sure if this is necessarily a good thing. > > Cheers, > Andy > > >

1 0

Re: (ITS#8639) Remove support for LANMAN
by andrew.lawrence＠siemens.com 03 Mar '18

03 Mar '18

Hi, Is this just the support for LANMAN hashes of passwords in slapd? There seems to also be some stand alone support for samba LANMAN passwords = in the smbk5pwd module. Cheers, Andy

1 0

Re: (ITS#8618) ldapsearch - unexpected behavior with
by andrew.lawrence＠siemens.com 03 Mar '18

03 Mar '18

@Alex The difference in behaviour is because it constructs a uri from the h= ostname and port. If there is no port you end up with an invalid uri. I am = not sure if this is necessarily a good thing. Cheers, Andy

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs