August 2009 - openldap-bugs

Re: (ITS#6271) syncprov use of freed mutex

by masarati＠aero.polimi.it

richton(a)nbcs.rutgers.edu wrote: > Full_Name: Aaron Richton > Version: RE24 > OS: Solaris 9 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (128.6.31.135) > > > Sol9+libumem+RE24 (current). I have five core files all with an aborting thread > showing: > > current thread: t@8 > [1] __lwp_kill(0x0, 0x6, 0x0, 0xfffffff8, 0x0, 0xfb3feec1), at 0xff31feb0 > [2] Abort(0xfb3fef18, 0xfb3fef18, 0x3a, 0x39, 0x81010100, 0xff00), at > 0xff056f9c > [3] panic(0xff065e34, 0x0, 0x0, 0x1, 0x0, 0xfb3ff139), at 0xff057094 > [4] _ceil_prio_inherit(0xef, 0x0, 0x10807258, 0xff078000, 0xff0613bc, 0x0), at > 0xff05ff10 > [5] mutex_lock_internal(0xad, 0x0, 0xff040e00, 0x23, 0x7, 0x10fed159), at > 0xff0614bc > =>[6] ldap_pvt_thread_mutex_lock(mutex = 0x10807258), line 296 in "thr_posix.c" > [7] syncprov_op_mod(op = 0xfb3ff8e8, rs = 0xfb3ff5a0), line 1965 in > "syncprov.c" > [8] overlay_op_walk(op = 0xfb3ff8e8, rs = 0xfb3ff5a0, which = op_modify, oi = > 0x1083b088, on = 0x1083ad88), line 659 in "backover.c" > [9] over_op_func(op = 0xfb3ff8e8, rs = 0xfb3ff5a0, which = op_modify), line > 721 in "backover.c" > [10] over_op_modify(op = 0xfb3ff8e8, rs = 0xfb3ff5a0), line 755 in > "backover.c" > [11] syncrepl_updateCookie(si = 0x10417a88, op = 0xfb3ff8e8, pdn = 0x10845b68, > syncCookie = 0xfb3ff710), line 3045 in "syncrepl.c" > [12] do_syncrep2(op = 0xfb3ff8e8, si = 0x10417a88), line 1177 in "syncrepl.c" > [13] do_syncrepl(ctx = 0xfb3ffe0c, arg = 0x10807d08), line 1358 in > "syncrepl.c" > [14] connection_read_thread(ctx = 0xfb3ffe0c, argv = 0x1c), line 1254 in > "connection.c" > [15] ldap_int_thread_pool_wrapper(xpool = 0x10491f08), line 685 in "tpool.c" > > In Frame 7, mt->mt_mods = 0xdeadbeef. Looks like libumem caught a post-free() > access. Looks like someone else got to the end of the modifications list and destroyed everything... p.

14 years, 3 months

1
0
0 / 0

(ITS#6271) syncprov use of freed mutex

by richton＠nbcs.rutgers.edu

Full_Name: Aaron Richton Version: RE24 OS: Solaris 9 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (128.6.31.135) Sol9+libumem+RE24 (current). I have five core files all with an aborting thread showing: current thread: t@8 [1] __lwp_kill(0x0, 0x6, 0x0, 0xfffffff8, 0x0, 0xfb3feec1), at 0xff31feb0 [2] Abort(0xfb3fef18, 0xfb3fef18, 0x3a, 0x39, 0x81010100, 0xff00), at 0xff056f9c [3] panic(0xff065e34, 0x0, 0x0, 0x1, 0x0, 0xfb3ff139), at 0xff057094 [4] _ceil_prio_inherit(0xef, 0x0, 0x10807258, 0xff078000, 0xff0613bc, 0x0), at 0xff05ff10 [5] mutex_lock_internal(0xad, 0x0, 0xff040e00, 0x23, 0x7, 0x10fed159), at 0xff0614bc =>[6] ldap_pvt_thread_mutex_lock(mutex = 0x10807258), line 296 in "thr_posix.c" [7] syncprov_op_mod(op = 0xfb3ff8e8, rs = 0xfb3ff5a0), line 1965 in "syncprov.c" [8] overlay_op_walk(op = 0xfb3ff8e8, rs = 0xfb3ff5a0, which = op_modify, oi = 0x1083b088, on = 0x1083ad88), line 659 in "backover.c" [9] over_op_func(op = 0xfb3ff8e8, rs = 0xfb3ff5a0, which = op_modify), line 721 in "backover.c" [10] over_op_modify(op = 0xfb3ff8e8, rs = 0xfb3ff5a0), line 755 in "backover.c" [11] syncrepl_updateCookie(si = 0x10417a88, op = 0xfb3ff8e8, pdn = 0x10845b68, syncCookie = 0xfb3ff710), line 3045 in "syncrepl.c" [12] do_syncrep2(op = 0xfb3ff8e8, si = 0x10417a88), line 1177 in "syncrepl.c" [13] do_syncrepl(ctx = 0xfb3ffe0c, arg = 0x10807d08), line 1358 in "syncrepl.c" [14] connection_read_thread(ctx = 0xfb3ffe0c, argv = 0x1c), line 1254 in "connection.c" [15] ldap_int_thread_pool_wrapper(xpool = 0x10491f08), line 685 in "tpool.c" In Frame 7, mt->mt_mods = 0xdeadbeef. Looks like libumem caught a post-free() access.

14 years, 3 months

1
0
0 / 0

Re: (ITS#6270) Conflict between ppolicy (pwdReset flag) and unique overlays

by clem.oudot＠gmail.com

2009/8/24 <michael(a)stroeder.com>: > clem.oudot(a)gmail.com wrote: >> Full_Name: Clement OUDOT >> Version: 2.4.16 >> OS: RHEL 5.2 >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (83.145.72.122) >> >> I use both ppolicy and unique overlays. >> >> I try to modify the password of an account whose pwdReset attribute is s= et to >> TRUE. I get this LDAP error: >> >> ldap_modify: Insufficient access (50) >> =A0 =A0 =A0 =A0 additional info: unique_search failed > > Without seeing your configuration one cannot determine wheter you're hitt= ing > ITS#6108: "unique overlay and rootdn". > > http://www.openldap.org/its/index.cgi/Documentation?id=3D6108;selectid=3D= 6108 > > Ciao, Michael. Hello, I have a rootdn. An extract of my slapd.conf is : --- database bdb suffix dc=3Dexample,dc=3Dcom rootdn cn=3Dmanager,dc=3Dexample,dc=3Dcom rootpw secret directory /var/lib/ldap overlay ppolicy ppolicy_use_lockout ppolicy_hash_cleartext overlay unique unique_uri ldap:///ou=3Dusers,dc=3Dexample,dc=3Dcom?uid?sub?(objectClass=3D= inetOrgPerson) --- Cl=E9ment.

14 years, 3 months

1
0
0 / 0

Re: (ITS#6270) Conflict between ppolicy (pwdReset flag) and unique overlays

by michael＠stroeder.com

clem.oudot(a)gmail.com wrote: > Full_Name: Clement OUDOT > Version: 2.4.16 > OS: RHEL 5.2 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (83.145.72.122) > > I use both ppolicy and unique overlays. > > I try to modify the password of an account whose pwdReset attribute is set to > TRUE. I get this LDAP error: > > ldap_modify: Insufficient access (50) > additional info: unique_search failed Without seeing your configuration one cannot determine wheter you're hitting ITS#6108: "unique overlay and rootdn". http://www.openldap.org/its/index.cgi/Documentation?id=6108;selectid=6108 Ciao, Michael.

14 years, 3 months

1
0
0 / 0

(ITS#6270) Conflict between ppolicy (pwdReset flag) and unique overlays

by clem.oudot＠gmail.com

Full_Name: Clement OUDOT Version: 2.4.16 OS: RHEL 5.2 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (83.145.72.122) Hello, I use both ppolicy and unique overlays. I try to modify the password of an account whose pwdReset attribute is set to TRUE. I get this LDAP error: ldap_modify: Insufficient access (50) additional info: unique_search failed In OpenLDAP logs, we can see: connection restricted to password changing only send_ldap_result: conn=20 op=2 p=3 send_ldap_result: err=50 matched="" text="Operations are restricted to bind/unbind/abandon/StartTLS/modify password" send_ldap_result: conn=20 op=2 p=3 send_ldap_result: err=50 matched="" text="unique_search failed" send_ldap_response: msgid=3 tag=103 err=50 So it seems the unique overlay cannot do a search because the connection is restricted by the ppolicy overlay.

14 years, 3 months

1
0
0 / 0

Re: (ITS#6266) uninitialized var in overlays/dynlist.c:dl_cfgen()

by masarati＠aero.polimi.it

> hyc(a)symas.com writes: >> In the actual code, dlm is initialized to NULL. Therefore, dlml will get >> initialized to NULL > > Only initialized when dml is NULL, but the test > 'if ( dlml != NULL )' below is unconditional. Then dlml goes > out of scope, it doesn't keep the value between iterations. Should be fixed now, thanks. Please test. p.

14 years, 3 months

1
0
0 / 0

Re: (ITS#6267) test030-relay fails with back-meta: line 79: kill: (23804) - No such process

by masarati＠aero.polimi.it

> masarati(a)aero.polimi.it wrote: >> Can't reproduce. > > Also happens with new checkout. See testrun/ available here: > > http://www.stroeder.com/temp/openldap-its6267-testrun-test030.tar.gz OK, that's about building as modules (back-meta needs back-ldap, should have tested straight ahead). Fixing... p.

14 years, 3 months

1
0
0 / 0

Re: (ITS#6267) test030-relay fails with back-meta: line 79: kill: (23804) - No such process

by michael＠stroeder.com

masarati(a)aero.polimi.it wrote: > Can't reproduce. Also happens with new checkout. See testrun/ available here: http://www.stroeder.com/temp/openldap-its6267-testrun-test030.tar.gz > Did you start from a fresh checkout? Is your working directory in sync with what's available through anon CVS? Ciao, Michael.

14 years, 3 months

1
0
0 / 0

(ITS#6269) Fails to include inter-library dependencies on QNX

by mkraai＠beckman.com

Full_Name: Matt Kraai Version: 2.4.17 OS: QNX 6.4.1 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (134.217.96.252) When built on QNX 6.4.1, libldap.so doesn't include inter-library dependency information. When an application tries to link against it, it fails because the symbols provided by the libraries that libldap.so should depend on aren't defined. Upgrading to a more recent version of libtool (e.g., 2.2.6) fixes this problem, since it knows how to handle inter-library dependencies on QNX. This can be done by installing libtool 2.2.6 and running the following commands in openldap's top-level source directory: aclocal libtoolize autoconf

14 years, 3 months

1
0
0 / 0

Re: (ITS#6268) multi-master sync replication ldap_add error code 68 bug

by hyc＠symas.com

bcolston(a)xtec.com wrote: > Full_Name: Barry Colston > Version: 2.4.17 > OS: Fedora 10 > URL: > Submission from: (NULL) (209.255.208.219) > > > While testing sync replication, I encountered a situation in which a previously > deleted DN cannot be added again because the ldapadd command receives a 68 error > code. If I perform an ldapsearch command for the DN, the DN is not found. If I > try to add the DN, the add fails with a 68 error code. If I perform a slapcat > command for that DN, slapcat displays the record. This sounds like it's related to ITS#6097. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

14 years, 3 months

1
0
0 / 0

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs August 2009