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
(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
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
(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
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
(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
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