openldap-bugs

openldap-bugs@openldap.org

1 participants
21515 discussions

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

Re: (ITS#8081) syncprov crash in syncprov_op_mod
by leo＠yuriev.ru 19 Mar '15

19 Mar '15

--047d7b87466456cd650511a30230 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Howard, I don't submit this path or so on. But you can see the bugs and fix it in openldap. Leonid 18.03.2015 22:17 =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: > >> Fixed in ReOpenLDAP week ago. >> https://github.com/ReOpen/ReOpenLDAP/commit/ >> 6de52172bc0f8309dd00c329452213d51e5573a9 >> > > Leo: if you intend for this patch to be adopted here, please attach the > IPR notice as documented > > http://www.openldap.org/devel/contributing.html > > Note that, as written, your patch is unacceptable as it violates the "one > functional change per patch" condition. > > -- > -- Howard Chu > CTO, Symas Corp. http://www.symas.com > Director, Highland Sun http://highlandsun.com/hyc/ > Chief Architect, OpenLDAP http://www.openldap.org/project/ > --047d7b87466456cd650511a30230 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Howard, I don't submit this path or so on. But you can s= ee the bugs and fix it in openldap. Leonid <div class=3D"gmail_quote">18.03.2015 22:17 =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"> Fixed in ReOpenLDAP week ago. <a href=3D"https://github.com/ReOpen/ReOpenLDAP/commit/6de52172bc0f8309dd00= c329452213d51e5573a9" target=3D"_blank">https://github.com/ReOpen/Re= OpenLDAP/commit/6de52172bc0f8309dd00c329452213d51e5573a9</a><= br> </blockquote> Leo: if you intend for this patch to be adopted here, please attach the IPR= notice as documented <a href=3D"http://www.openldap.org/devel/contributing.html" target=3D"_blan= k">http://www.openldap.org/devel/contributing.html</a> Note that, as written, your patch is unacceptable as it violates the "= one functional change per patch" condition. -- =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> --047d7b87466456cd650511a30230--

1 0

Re: (ITS#8081) syncprov crash in syncprov_op_mod
by ryan＠nardis.ca 18 Mar '15

18 Mar '15

On Wed, Mar 18, 2015 at 05:06:33AM +0000, ryan(a)nardis.ca wrote: >I get the following crash on master and RE24. not every time, but most times. > >Program received signal SIGSEGV, Segmentation fault. >[Switching to Thread 0x7fffe6ffe700 (LWP 25923)] >0x0000000000511d45 in syncprov_op_mod (op=0x7fffd41024a0, rs=0x7fffe6ffdae0) at >syncprov.c:2129 >2129 if ( m2->mi_op->o_threadctx == op->o_threadctx ) { Same testcase, different crash: Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x7fffecde1700 (LWP 1747)] 0x000000000051ae5e in syncprov_op_cleanup (op=0x7fffe0000aa0, rs=0x7fffecde0ac0) at syncprov.c:1418 1418 mt->mt_mods = mt->mt_mods->mi_next; (gdb) bt #0 0x000000000051ae5e in syncprov_op_cleanup (op=0x7fffe0000aa0, rs=0x7fffecde0ac0) at syncprov.c:1418 #1 0x00000000004417f3 in slap_cleanup_play (op=0x7fffe0000aa0, rs=0x7fffecde0ac0) at result.c:567 #2 0x0000000000441fac in send_ldap_response (op=0x7fffe0000aa0, rs=0x7fffecde0ac0) at result.c:759 #3 0x0000000000442793 in slap_send_ldap_result (op=0x7fffe0000aa0, rs=0x7fffecde0ac0) at result.c:886 #4 0x00000000004e472a in mdb_modify (op=0x7fffe0000aa0, rs=0x7fffecde0ac0) at modify.c:672 #5 0x00000000004baadd in overlay_op_walk (op=0x7fffe0000aa0, rs=0x7fffecde0ac0, which=op_modify, oi=0x8aae60, on=0x0) at backover.c:696 #6 0x00000000004bad01 in over_op_func (op=0x7fffe0000aa0, rs=0x7fffecde0ac0, which=op_modify) at backover.c:749 #7 0x00000000004bae35 in over_op_modify (op=0x7fffe0000aa0, rs=0x7fffecde0ac0) at backover.c:788 #8 0x000000000044bacb in fe_op_modify (op=0x7fffe0000aa0, rs=0x7fffecde0ac0) at modify.c:303 #9 0x000000000044b37e in do_modify (op=0x7fffe0000aa0, rs=0x7fffecde0ac0) at modify.c:177 #10 0x000000000042bdf3 in connection_operation (ctx=0x7fffecde0bf0, arg_v=0x7fffe0000aa0) at connection.c:1134 #11 0x000000000042c3a3 in connection_read_thread (ctx=0x7fffecde0bf0, argv=0xb) at connection.c:1280 #12 0x000000000053772e in ldap_int_thread_pool_wrapper (xpool=0x883b40) at tpool.c:958 #13 0x00007ffff77ad0a4 in start_thread (arg=0x7fffecde1700) at pthread_create.c:309 #14 0x00007ffff74e204d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111 Looks like at this point mt either points to garbage, or is itself garbage. Reverting 8eb9aa7d resolves both crashes.

1 0

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs