openldap-bugs

openldap-bugs@openldap.org

1 participants
20967 discussions

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). </div> </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). </div><div class=3D"gmail_extra"= > <div class=3D"gmail_quote">On Sun, Mar 22, 2015 at 12:39 AM, Howard Ch= u <<a href=3D"mailto:hyc@symas.com" target=3D"_blank">= hyc(a)symas.com</a>> wrote: <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: <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 Version: 2.4.40 OS: Debian URL: <a href=3D"ftp://ftp.openldap.org/incoming/NikosVoutsinas_20-03-2015_m= db_assertion.id2entry" target=3D"_blank">ftp://ftp.openldap.org/inco= ming/NikosVoutsinas_20-03-2015_mdb_assertion.id2entry</a> Submission from: (NULL) (5.55.167.101) slapd with an mdb backend, after some time of normal operation, may reach i= nto a situation where you can almost predictably crash it, with a simple modify<b= r> operation. </blockquote> Please test RE24 and see if you can still reproduce this issue. -- =C2=A0 -- Howard Chu =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> =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> =C2=A0 Chief Architect, OpenLDAP=C2=A0 <a href=3D"http://www.openldap.org/p= roject/" target=3D"_blank">http://www.openldap.org/project/</a> </blockquote></div> </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

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

19 Mar '15

1 0

Re: (ITS#8062) Assertion 'IS_LEAF(mp)' failed in mdb_cursor_next()
by leo＠yuriev.ru 19 Mar '15

19 Mar '15

--001a113602ac48c9b00511a317b0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hm, in some case valgrind was reported as I noticed, sure 101%. Leonid 18.03.2015 23:12 =D0=BF=D0=BE=D0=BB=D1=8C=D0=B7=D0=BE=D0=B2=D0=B0=D1=82=D0= =B5=D0=BB=D1=8C "Howard Chu" <hyc(a)symas.com> =D0=BD=D0=B0=D0=BF=D0=B8=D1=81= =D0=B0=D0=BB: > leo(a)yuriev.ru wrote: > >> As far as I remember this was fixed in ReOpenLDAP at January. >> Valgrind was reporting 'using uninitialized'. >> > > Not happening here. mdb_cursor_first() always initializes mc_ki. > >> >> Leonid. >> >> @@ -7301,6 +7551,7 @@ mdb_cursor_init(MDB_cursor *mc, MDB_txn *txn, >> MDB_dbi dbi, MDB_xcursor *mx) >> mc->mc_top =3D 0; >> mc->mc_pg[0] =3D 0; >> mc->mc_flags =3D 0; >> + mc->mc_ki[0] =3D 0; >> if (txn->mt_dbs[dbi].md_flags & MDB_DUPSORT) { >> mdb_tassert(txn, mx !=3D NULL); >> mc->mc_xcursor =3D mx; >> >> >> >> >> >> > > -- > -- Howard Chu > CTO, Symas Corp. http://www.symas.com > Director, Highland Sun http://highlandsun.com/hyc/ > Chief Architect, OpenLDAP http://www.openldap.org/project/ > --001a113602ac48c9b00511a317b0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hm, in some case valgrind was reported as I noticed, sure 10= 1%. Leonid <div class=3D"gmail_quote">18.03.2015 23:12 =D0=BF=D0=BE=D0=BB=D1=8C=D0=B7= =D0=BE=D0=B2=D0=B0=D1=82=D0=B5=D0=BB=D1=8C "Howard Chu" <<a hr= ef=3D"mailto:hyc@symas.com">hyc(a)symas.com</a>> =D0=BD=D0=B0=D0=BF=D0=B8= =D1=81=D0=B0=D0=BB: <blockquote class=3D"gmail_quot= e" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">= <a href=3D"mailto:leo@yuriev.ru" target=3D"_blank">leo(a)yuriev.ru</a> wrote:= <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> As far as I remember this was fixed in ReOpenLDAP at January. Valgrind was reporting 'using uninitialized'. </blockquote> Not happening here. mdb_cursor_first() always initializes mc_ki. <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> Leonid. @@ -7301,6 +7551,7 @@ mdb_cursor_init(MDB_cursor *mc, MDB_txn *txn, MDB_dbi dbi, MDB_xcursor *mx) =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 mc->mc_top =3D 0; =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 mc->mc_pg[0] =3D 0; =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 mc->mc_flags =3D 0; +=C2=A0 =C2=A0 =C2=A0 =C2=A0mc->mc_ki[0] =3D 0; =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 if (txn->mt_dbs[dbi].md_flags & M= DB_DUPSORT) { =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 mdb_tassert(= txn, mx !=3D NULL); =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 mc->mc_xc= ursor =3D mx; </blockquote> -- =C2=A0 -- Howard Chu =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> =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> =C2=A0 Chief Architect, OpenLDAP=C2=A0 <a href=3D"http://www.openldap.org/p= roject/" target=3D"_blank">http://www.openldap.org/project/</a> </blockquote></div> --001a113602ac48c9b00511a317b0--

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs