openldap-bugs March 2015

openldap-bugs@openldap.org

25 participants
65 discussions

(ITS#8087) Segmentation fault in MDB at idl.c:91 using searches
by francisco＠garnelo.eu 24 Mar '15

24 Mar '15

Full_Name: Francisco Garnelo Version: slapd 2.4.40 OS: FreeBSD 10.1-STABLE URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (194.237.142.21) Hi, when I try to access with a LDAP browser (Apache DS) and the browser begin to enumerate the items in differents branches, the server crashes; this not takes more than 30 seconds from last restart. I experimented a similar issue with SLES 12(if not it is the same) and openldap 2.4.40 (from suse repositories) version, but in this system I could not take evidences. The database has more than 3GB of size and MDB is configured to support 100GB as the maximum size. The same databa w works fine ining BDB using an old openldap version. ############# # Versions: # ############# root@XXXX:/usr/local/etc/openldap # /usr/local/libexec/slapd -VVV @(#) $OpenLDAP: slapd 2.4.40 (Mar 24 2015 17:18:46) $ root@XXXX:/usr/rtrts/net/openldap24-server/work/openldap-2.4.40/servers/slapd Included static overlays: dynlist seqmod syncprov Included static backends: config ldif relay root@xxxx:/usr/local/etc/openldap # uname -a FreeBSD xxxx 10.1-STABLE FreeBSD 10.1-STABLE #0 r278906: Tue Feb 17 19:09:13 UTC 2015 root@releng1.nyi.freebsd.org:/usr/obj/usr/src/sys/GENERIC amd64 ###################### # cn=config export: # ###################### version: 1 dn: cn=config objectClass: olcGlobal cn: config olcArgsFile: /var/run/openldap/slapd.args olcAttributeOptions: lang- olcAuthzPolicy: none olcConfigDir: slapd.d olcConfigFile: slapd.conf olcIdleTimeout: 0 olcIndexIntLen: 8 olcIndexSubstrAnyLen: 4 olcIndexSubstrAnyStep: 2 olcIndexSubstrIfMaxLen: 4 olcIndexSubstrIfMinLen: 2 olcListenerThreads: 1 olcLocalSSF: 71 olcLogLevel: 0 olcPidFile: /var/run/openldap/slapd.pid olcReadOnly: FALSE olcReverseLookup: FALSE olcSizeLimit: unlimited olcThreads: 20 olcTLSCACertificateFile: /usr/local/etc/openldap/certs/public/ca.crt olcTLSCertificateFile: /usr/local/etc/openldap/certs/public/server.crt olcTLSCertificateKeyFile: /usr/local/etc/openldap/certs/private/server.key olcTLSCRLCheck: none olcTLSProtocolMin: 0.0 olcTLSVerifyClient: never olcToolThreads: 2 olcWriteTimeout: 0 dn: cn=module{0},cn=config objectClass: olcModuleList cn: module{0} olcModuleLoad: {0}back_mdb database config olcModulePath: /usr/local/libexec/openldap dn: cn=schema,cn=config objectClass: olcSchemaConfig cn: schema ### -- omitted content -- ### include /usr/local/etc/openldap/schema/core.schema include /usr/local/etc/openldap/schema/cosine.schema include /usr/local/etc/openldap/schema/inetorgperson.schema include /r%r/local/etc/openldap/schema/rfc2307bis.schema ### -- omitted content -- ### dn: olcDatabase={-1}frontend,cn=config objectClass: olcFrontendConfig objectClass: olcDatabaseConfig olcDatabase: {-1}frontend olcAccess: {0}to dn.base="" by * read olcAccess: {1}to dn.base%%2"cn=subsemema" by * read olcAccess: {2}to attrs=shadowLastChange by self write by * read olcAccess: {3}to * by * read olcAddContentAcl: FALSE olcLastMod: TRUE olcMaxDerefDepth: 0 olcMonitoring: FALSE olcReadOnly: FALSE olcSchemaDN: cn=Subschema olcSizeLimit: unlimited olcSyncUseSubentry: FALSE dn: olcDatabase={0}config,cn=config objectClass: olcDatabaseConfig olcDatabase: {0}config olcAccess: {0}to * by * none olcAddContentAcl: TRUE olcLastMod: TRUE olcMaxDerefDepth: 15 olcMonitoring: FALSE olcReadOnly: FALSE olcRootDN: cn=config olcRootPW: XXXXX olcSyncUseSubentry: FALSE dn: olcDatabase={1}mdb,cn=config objectClass: olcMdbConfig objectClass: olcDatabaseConfig olcDatabase: {1}mdb olcDbDirectory:2F2Fvar/db/openldap-data.mdb olcDbIndex: objectClass eq olcRootDN: cn=lalala,dc=yyyyyyy,dc=com olcRootPW: XXXXXXX olcSuffix: dc=yyyyyyy,dc=com ######## # GDB: # ######## 551194b6 => mdb_dn2id("lelreleID=6666999999(a)lol.com,ou=molon,dc=yyyyyyy,%3=com") 551194b6 <= mdb_entry_decode 551194b6 <= mdb_dn2id: got id=0x92b0 551194b6 => mdb_entry_decode: 551194b6 => mdb_entry_decode: 551194b6 <= mdb_entry_decode 551194b6 => mdb_entry_decode: 551194b6 => mdb_entry_decode: 551194b6 <= mdb_entry_decode 551194b6 <= mdb_entry_decode 551194b6 => mdb_entry_decode: 551194b6 => mdb_entry_decode: 551194b6 <= mdb_entry_decode 551194b6 <= mdb_entry_decode 551194b6 mdb_dn2entry("lelreleID=6666999999(a)lol.com,ou=molon,dc=yyyyyyy,dc=com") 551194b6 => mdb_entry_decode: 551194b6 => mdb_dn2id("lelreleID=6666999999(a)lol.com,ou=molon,dc=yyyyyyy,dc=com") 551194b6 <= mdb_entry_decode 551194b6 <= mdb_entry_decode 551194b6 => mdb_entry_decode: 551194b6 => mdb_entry_decode: 551194b6 <= mdb_entry_decode 551194b6 <= mdb_dn2id: got id=0x92b0 551194b6 => mdb_entry_decode: 551194b6 <= mdb_entry_decode 551194b6 => mdb_entry_decode: 551194b6 => mdb_entry_decode: 551194b6 <= mdb_entry_decode 551194b6 <= mdb_entry_decode 551194b6 => mdb_entry_decode: 551194b6 <=dbdb_entry_decode 551194b6 => mdb_entry_decode: 551194b6 => mdb_entry_decode: 551194b6 <= mdb_entry_decode 551194b6 <= mdb_entry_decode 551194b6 => mdb_entry_decode: 551194b6 <= mdb_entry_decode 551194b6 => mdb_entry_decode: 551194b6 => mdb_entry_decode: 551194b6 <= mdb_entry_decode 551194b6 <= mdb_entry_decode 551194b6 mdb_dn2entry("lelreleID=luser123(a)odin.lala,ou=molon,dc=yyyyyyy,dc=com") 551194b8 => mdb_dn2id("lelreleID=luser123(a)odin.lala,ou=molon,dc=yyyyyyy,dc=com") 551194b8 <= mdb_dn2id: got id=0x931e 551194b8 => mdb_entry_decode: 551194b8 <= mdb_entry_decode 551194b6 => mdb_entry_decode: 551194b8 => mdb_entry_decode: 551194b8 <= mdb_entry_decode 551194b8 <= mdb_entry_decode 551194b7 daemon: activity on 1 descriptor 551194b8 daemon: activity on:519194b8 11r551194b8 551194b8 daemon: read activity on 11 551194b8 mdb_dn2entry("lelreleID=6666999990(a)lol.com,ou=molon,dc=yyyyyyy,dc=com") 551194b8 => mdb_dn2id("lelreleID=6666999990(a)lol.com,ou=molon,dc=yyyyyyy,dc=com") 551194b7 => mdb_entry_decode: 551194b7 => mdb_entry_decode: 551194b8 <= mdb_entry_decode 551194b8 <= mdb_dn2id: got id=0x9321 551194b8 mdb_dn2entry("loloId=50,ou=fry,dc=yyyyyyy,dc=com") 551194b8 => mdb_entry_decode: 551194b8 => mdb_dn2id("loloId=50,ou=fry,dc=yyyyyyy,dc=com") 551194b8 <= mdb_entry_decode 551194b8 => mdb_entry_decode: 551194b8 daemon: select: listen=6 active_threads=0 tvp=NULL 551194b8 daemon: select: listen=7 active_threads=0 tvp=NULL 551194b8 <= mdb_dn2id: got id=0xf 551194b6 <= mdb_entry_decode 551194b8 => mdb_entry_dece:3A 551194b8 <= mdb_entry_decode 551194b8 => mdb_entry_decode: 551194b8 <= mdb_entry_decode 551194b8 <= mdb_entry_decode 551194b8 <= mdb_entry_decode 551194b8 => mdb_entry_decode: 551194b8 mdb_dn2entry("lelreleID=6666999990(a)lol.com,ou=molon,dc=yyyyyyy,dc=com") 551194b8 => mdb_dn2id("lelreleID=6666999990(a)lol.com,ou=molon,dc=yyyyyyy,dc=com") 551194b8 <= mdb_entry_decode 551194b8 mdb_dn2entry("lelreleID=262280000000000(a)lol.com,ou=molon,dc=yyyyyyy,dc=com") 551194b8 => mdb_entry_decode: 551194b8 <= mdb_entry_decode 551194b8 => mdb_entry_decode: 551194b8 => mdb_entry_decode: 551194b8 <= mdb_entry_decode 551194b8 => mdb_entry_decode: 551194b8 <= mdb_dn2id: got id=0x9321 551194b8 <= mdb_entry_decode 551194b8 => mdb_entry_decode: 551194b8 <= mdb_entry_decode 551194b8 => mdb_dn2id("lelreleID=262280000000000(a)lol.com,ou=molon,dc=yyyyyyy,dc=com") 551194b8 => mdb_entry_decode: 551194b8 <= mdb_entry_decode 551194b8 <= mdb_dn2id: got id=0x25 551194b8 => mdb_entry_decode: 551194b8 <= mdb_entry_decode 551194b8 => mdb_entry_decode: 551194b8 mdb_dn2entry("loloId=50,ou=fry,dc=yyyyyyy,dc=com") 551194b8 <= mdb_entry_decode [New Thread 2103c12400 (LWP 100750/slapd)] Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 2103c12400 (LWP 100750/slapd)] 0x00000008024a579f in mdb_idl_search (ids=0x210a980000, id=37) at idl.c:91 91 val = IDL_CMP( id, ids[cursor] ); Current language: auto; currently minimal -------------- Thanks, Francisco Garnelo

1 0

Re: (ITS#7008) paged results against ldap-proxy errors with 'cookie is invalid'
by whm＠stanford.edu 23 Mar '15

23 Mar '15

This one just bit us again. I know that the client should probably not be using pr at all, but the client is an Google supplied intergration application that we have little control over. Is this a problem that is going to be addressed as some point or will it be treated as a known limitation? Bill -- "We have meet the enemy and he is us." Pogo

1 0

Re: (ITS#8086) slapd with mdb backend crashes in id2entry
by hyc＠symas.com 22 Mar '15

22 Mar '15

Nikos Voutsinas wrote: > I am in the process of doing so. Do you have in mind a specific > commit/fix in REL_EN that might have solved this; That would help me > reproduce the initial problem (in 2.4.40) and confirm the fix (in REL_ENG). Most likely 9a72292ac134f80c1befe8102dee1160e57a92ec > > For start I will try to upgrade to REL_ENG the same system from which I > got the debug log, to see if that would help recover (although I have no > great hopes). > > On Sun, Mar 22, 2015 at 12:39 AM, Howard Chu <hyc(a)symas.com > <mailto:hyc@symas.com>> wrote: > > nvoutsin(a)gmail.com <mailto:nvoutsin@gmail.com> wrote: > > Full_Name: Nikos Voutsinas > Version: 2.4.40 > OS: Debian > URL: > ftp://ftp.openldap.org/__incoming/NikosVoutsinas_20-03-__2015_mdb_assertion… > <ftp://ftp.openldap.org/incoming/NikosVoutsinas_20-03-2015_mdb_assertion.id2…> > Submission from: (NULL) (5.55.167.101) > > > slapd with an mdb backend, after some time of normal operation, > may reach into a > situation where you can almost predictably crash it, with a > simple modify > operation. > > > Please test RE24 and see if you can still reproduce this issue. > > -- > -- Howard Chu > CTO, Symas Corp. http://www.symas.com > Director, Highland Sun http://highlandsun.com/hyc/ > Chief Architect, OpenLDAP http://www.openldap.org/__project/ > <http://www.openldap.org/project/> > > -- -- 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#8086) slapd with mdb backend crashes in id2entry
by nvoutsin＠gmail.com 22 Mar '15

22 Mar '15

--001a1141ca9eb03add0511dda290 Content-Type: text/plain; charset=UTF-8 I am in the process of doing so. Do you have in mind a specific commit/fix in REL_EN that might have solved this; That would help me reproduce the initial problem (in 2.4.40) and confirm the fix (in REL_ENG). For start I will try to upgrade to REL_ENG the same system from which I got the debug log, to see if that would help recover (although I have no great hopes). On Sun, Mar 22, 2015 at 12:39 AM, Howard Chu <hyc(a)symas.com> wrote: > nvoutsin(a)gmail.com wrote: > >> Full_Name: Nikos Voutsinas >> Version: 2.4.40 >> OS: Debian >> URL: ftp://ftp.openldap.org/incoming/NikosVoutsinas_20-03- >> 2015_mdb_assertion.id2entry >> Submission from: (NULL) (5.55.167.101) >> >> >> slapd with an mdb backend, after some time of normal operation, may reach >> into a >> situation where you can almost predictably crash it, with a simple modify >> operation. >> > > Please test RE24 and see if you can still reproduce this issue. > > -- > -- Howard Chu > CTO, Symas Corp. http://www.symas.com > Director, Highland Sun http://highlandsun.com/hyc/ > Chief Architect, OpenLDAP http://www.openldap.org/project/ > --001a1141ca9eb03add0511dda290 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div><div>I am in the process of doing so. Do you have in = mind a specific commit/fix in REL_EN that might have solved this; That woul= d help me reproduce the initial problem (in 2.4.40) and confirm the fix (in= REL_ENG). <br></div><br></div>For start I will try to upgrade to REL_ENG t= he same system from which I got the debug log, to see if that would help re= cover (although I have no great hopes).<br></div><div class=3D"gmail_extra"= ><br><div class=3D"gmail_quote">On Sun, Mar 22, 2015 at 12:39 AM, Howard Ch= u <span dir=3D"ltr"><<a href=3D"mailto:hyc@symas.com" target=3D"_blank">= hyc(a)symas.com</a>></span> wrote:<br><blockquote class=3D"gmail_quote" st= yle=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><a hr= ef=3D"mailto:nvoutsin@gmail.com" target=3D"_blank">nvoutsin(a)gmail.com</a> w= rote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> Full_Name: Nikos Voutsinas<br> Version: 2.4.40<br> OS: Debian<br> URL: <a href=3D"ftp://ftp.openldap.org/incoming/NikosVoutsinas_20-03-2015_m= db_assertion.id2entry" target=3D"_blank">ftp://ftp.openldap.org/<u></u>inco= ming/NikosVoutsinas_20-03-<u></u>2015_mdb_assertion.id2entry</a><br> Submission from: (NULL) (5.55.167.101)<br> <br> <br> slapd with an mdb backend, after some time of normal operation, may reach i= nto a<br> situation where you can almost predictably crash it, with a simple modify<b= r> operation.<br> </blockquote> <br> Please test RE24 and see if you can still reproduce this issue.<span class= =3D"HOEnZb"><font color=3D"#888888"><br> <br> -- <br> =C2=A0 -- Howard Chu<br> =C2=A0 CTO, Symas Corp.=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<a href=3D"= http://www.symas.com" target=3D"_blank">http://www.symas.com</a><br> =C2=A0 Director, Highland Sun=C2=A0 =C2=A0 =C2=A0<a href=3D"http://highland= sun.com/hyc/" target=3D"_blank">http://highlandsun.com/hyc/</a><br> =C2=A0 Chief Architect, OpenLDAP=C2=A0 <a href=3D"http://www.openldap.org/p= roject/" target=3D"_blank">http://www.openldap.org/<u></u>project/</a><br> </font></span></blockquote></div><br></div> --001a1141ca9eb03add0511dda290--

1 0

Re: (ITS#8086) slapd with mdb backend crashes in id2entry
by hyc＠symas.com 21 Mar '15

21 Mar '15

nvoutsin(a)gmail.com wrote: > Full_Name: Nikos Voutsinas > Version: 2.4.40 > OS: Debian > URL: ftp://ftp.openldap.org/incoming/NikosVoutsinas_20-03-2015_mdb_assertion.id2… > Submission from: (NULL) (5.55.167.101) > > > slapd with an mdb backend, after some time of normal operation, may reach into a > situation where you can almost predictably crash it, with a simple modify > operation. Please test RE24 and see if you can still reproduce this issue. -- -- 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#8084) Segfault on ppc64 caused by commit 6ad38fef3fe63ff86c1e6cff3c6330353b21cc24
by hyc＠symas.com 20 Mar '15

20 Mar '15

jsynacek(a)redhat.com wrote: > jsynacek(a)redhat.com writes: > >> I bisected the problem and the following commit is the problem: >> commit 6ad38fef3fe63ff86c1e6cff3c6330353b21cc24 >> Author: Howard Chu <hyc(a)openldap.org> >> Date: Wed Jan 14 19:05:17 2015 +0000 >> >> Fix typo in 45146ba21a9ee494e7058ca7a173fcc6b27df744 >> >> diff --git a/servers/slapd/schema_init.c b/servers/slapd/schema_init.c >> index 46d1c6d..08e733f 100644 >> --- a/servers/slapd/schema_init.c >> +++ b/servers/slapd/schema_init.c >> @@ -1826,7 +1826,7 @@ UTF8StringValidate( >> if( LDAP_UTF8_OFFSET( (char *)u ) != len ) return >> LDAP_INVALID_SYNTAX; >> } >> >> - if( u >= len ) { >> + if( u > end ) { >> return LDAP_INVALID_SYNTAX; >> } > > This commit obviously doesn't have anything to do with the crash. I'm > not sure why the crash is triggered from this commit onward. > > The real issue seems to be the attribute usage in mdb.c: > > # define ESECT __attribute__ ((section("text_env"))) > > If ESECT is simply removed, the crash goes away. Sounds like a ppc64 binutils bug then. You can #if 0 that definition for ppc64 if you want, since it's only a small optimization for text segment size. But if ppc64 is using standard ELF binary format, this should not be breaking. -- -- 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#8084) Segfault on ppc64 caused by commit 6ad38fef3fe63ff86c1e6cff3c6330353b21cc24
by jsynacek＠redhat.com 20 Mar '15

20 Mar '15

jsynacek(a)redhat.com writes: > I bisected the problem and the following commit is the problem: > commit 6ad38fef3fe63ff86c1e6cff3c6330353b21cc24 > Author: Howard Chu <hyc(a)openldap.org> > Date: Wed Jan 14 19:05:17 2015 +0000 > > Fix typo in 45146ba21a9ee494e7058ca7a173fcc6b27df744 > > diff --git a/servers/slapd/schema_init.c b/servers/slapd/schema_init.c > index 46d1c6d..08e733f 100644 > --- a/servers/slapd/schema_init.c > +++ b/servers/slapd/schema_init.c > @@ -1826,7 +1826,7 @@ UTF8StringValidate( > if( LDAP_UTF8_OFFSET( (char *)u ) != len ) return > LDAP_INVALID_SYNTAX; > } > > - if( u >= len ) { > + if( u > end ) { > return LDAP_INVALID_SYNTAX; > } This commit obviously doesn't have anything to do with the crash. I'm not sure why the crash is triggered from this commit onward. The real issue seems to be the attribute usage in mdb.c: # define ESECT __attribute__ ((section("text_env"))) If ESECT is simply removed, the crash goes away. -- Jan Synacek Software Engineer, Red Hat

1 0

(ITS#8086) slapd with mdb backend crashes in id2entry
by nvoutsin＠gmail.com 19 Mar '15

19 Mar '15

Full_Name: Nikos Voutsinas Version: 2.4.40 OS: Debian URL: ftp://ftp.openldap.org/incoming/NikosVoutsinas_20-03-2015_mdb_assertion.id2… Submission from: (NULL) (5.55.167.101) slapd with an mdb backend, after some time of normal operation, may reach into a situation where you can almost predictably crash it, with a simple modify operation. Unfortunately, it is not clear, what are the exact steps that trigger the first crash, but once this happens, the pattern after is rather standard. After the initial crash, you restart slapd and you send a single modify operation on any single attribute, the operation completes successfully. You send again the same modify operation, and slapd crashes in servers/slapd/back-mdb/id2entry.c:520: mdb_opinfo_get. I know that the description doesn't say much, but I am not sure what can I do to narrow down the problem. However I managed to catch this in a log file (assertion.id2entry) with full debug flags and I hope that someone may see into this something, that I can not. The DIT and the database come from a testing system, are very small in size and I can send them if that helps. The cn=config on the other hand is rather complicated as it includes an MMR and many other options. btw the same crashes have happened in both masters. Best Regards. Nikos

1 0

Re: (ITS#8085) Segfault on ppc64 caused by commit 6ad38fef3fe63ff86c1e6cff3c6330353b21cc24
by jsynacek＠redhat.com 19 Mar '15

19 Mar '15

jsynacek(a)redhat.com writes: > Full_Name: Jan Synacek > Version: master > OS: GNU/Linux > URL: > Submission from: (NULL) (213.175.37.10) > > > On PPC64, slapd segfaults on startup when using mdb as the backend. For some reason, this bug got submitted twice. Sorry for double posting. -- Jan Synacek Software Engineer, Red Hat

1 0

(ITS#8085) Segfault on ppc64 caused by commit 6ad38fef3fe63ff86c1e6cff3c6330353b21cc24
by jsynacek＠redhat.com 19 Mar '15

19 Mar '15

Full_Name: Jan Synacek Version: master OS: GNU/Linux URL: Submission from: (NULL) (213.175.37.10) On PPC64, slapd segfaults on startup when using mdb as the backend. Reproducer: 1) ./configure && make && make install STRIP="" 2) slapd -d1 -h "ldap:/// ldapi:///" -f slapd.conf $ cat slapd.conf include /etc/opldldap/schema/core.schema include /etc/openldap/schema/cosine.schema include /etc/openldap/schema/inetorgperson.schema include /etc/openldap/schema/nis.schema allow bind_v2 pidfile /var/run/openldap/slapd.pid argsfile /var/run/openldap/slapd.args database mdb directory /var/lib/ldap/ suffix dc=foo,dc=bar,dc=com rootdn "cn=Manager,dc=foo,dc=bar,dc=com" # password is 'x' rootpw {SSHA}tOSmeQCcYIm1S9ujgpg2Km5rpUnR9dRBD%D There seems to be a program memory corruption, since the backtrace doesn't make any sense and valgrind reports "Illegal instruction". gdb --args -d1 -h "ldap:/// ldapi:///" -f slapd.conf ... (gdb) r ... Program received signal SIGSEGV, Segmentation fault. 0x000000001014b98c in 000006ae.plt_call.pthread_mutex_unlock@@GLIBC_2.3+0 () (gdb) bt #0 0x000000001014b98c in 000006ae.plt_call.pthread_mutex_unlock@@GLIBC_2.3+0 () #1 0x000000001014d79c in mdb_env_open (env=0x1034a4e0, path=0x102d5250 "/var/lib/ldap/", flags=536870912, mode=<value optimized out>) at ./../../../libraries/liblmdb/mdb.c:4540 #2 0x00000000100b91d4 in mdb_db_open (be=0x102b02c0, cr=0xfffffffe9a0) at init.c:174 #3 0x000000001003c130 in backend_startup_one (be=0x102b02c0, cr=0xfffffffe9a0) at backend.c:224 #4 0x000000001003c58c in backend_startup (be=0x102b02c0) at backend.c:330 #5 0x000000001005d650 in slap_startup (be=0x0) at init.c:220 #6 0x0000000010009b88 in main (argc=<value optimized out>, argv=<value optimized out>) at main.c:997 (gdb) up #1 0x000000001014d79c in mdb_env_open (env=0x1034a4e0, path=0x102d5250 "/var/lib/ldap/", flags=536870912, mode=<value optimized out>) at ./../../../libraries/liblmdb/mdb.c:4540 4540 env->me_path = strdup(path); I bisected the problem and the following commit is the problem: commit 6ad38fef3fe63ff86c1e6cff3c6330353b21cc24 Author: Howard Chu <hyc(a)openldap.org> Date: Wed Jan 14 19:05:17 2015 +0000 Fix typo in 45146ba21a9ee494e7058ca7a173fcc6b27df744 diff --git a/servers/slapd/schema_init.c b/servers/slapd/schema_init.c index 46d1c6d..08e733f 100644 --- a/servers/slapd/schema_init.c +++ b/servers/slapd/schema_init.c @@ -1826,7 +1826,7 @@ UTF8StringValidate( if( LDAP_UTF8_OFFSET( (char *)u ) != len ) return LDAP_INVALID_SYNTAX; } - if( u >= len ) { + if( u > end ) { return LDAP_INVALID_SYNTAX; } This problem is already present in 2.4.40, but absent in 2.4.39.

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs March 2015